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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://ipr.etsi.org ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by ETSI Technical Committee Machine-to-Machine 
communications (M2M). 
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Scope 



The present document specifies Interoperability Test Descriptions (TDs) for the CoAP binding as specified in Annex D 
of TS 102 921 [5]. The Test Descriptions cover the CoAP protocol specification where relevant. The purpose of the 
interoperability testing is to prove that end-to-end functionality between devices such as: 

• D' and GSCL 

• or D' and GSCL and NSCL and NA 

and using CoAP as underlying application layer, is as required by the standard(s) on which those devices are based. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 
[ 1 ] draft- ietf-core-coap- 12:" Constrained Apphcation Protocol (CoAP) " . 

NOTE: Available at: http://tools.ietf.org/html/draft-ietf-core-coap-12 . 
[2] IETF RFC 6690: "Constrained RESTfiil Environments (CoRE) Link Forma". 

[3] draft-ietf-core-observe-08: "Observing Resources in CoAP". 

NOTE: Available at: http://tools.ietf.org/html/draft-ietf-core-observe-08 . 
[4] draft-ietf-core-block-10: "Blockwise transfers in CoAP". 

[5] ETSI TS 102 921: "Machine-to-Machine communications (M2M); mla, dia and mid interfaces". 

[6] ETSI TS 102 690: "Machine-to-Machine communications (M2M); Functional architecture". 

2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

Not applicable. 
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3.1 



Definitions and abbreviations 



Definitions 



For the purposes of the present document, the following terms and definitions apply: 
Device' (D'): Hosts DA that communicates to a GSCL using the dia reference point 
application Point of Contract (aPoC): URI that identifies how requests are re-targeted 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 



ACK 

aPoC 

CFG 

CoAP 

CON 

CORE 

D' 

DA 

dIa 

BUT 

GSCL 

mla 

mid 

NA 

NON 

NSCL 

OBS 

RST 

SCL 

TD 

UDP 

URI 

XML 



Acknowledgement 

application Point of Contract 

ConFigGuration 

Constrained Application Protocol 

Confirmable 

Constrained RESTful Environment 

Device' 

Device Application 

device application Interface 

Equipment Under Test 

Gateway SCL 

M2M application Interface 

M2M device Interface 

Network Application 

Non-Confirmable 

Network SCL 

OBServe 

Reset 

Service Capability Layer 

Test Description 

User Datagram Protocol 

Universal Resource Identifier 

extensible Markup Language 



Conventions 



4.1 The Test Description proforma 

The test descriptions are provided in proforma tables. The following different types of test operator actions are 
considered during the test execution: 

• A stimulus corresponds to an event that enforces an EUT to proceed with a specific protocol action, like 
sending a message for instance. 

• A verify consists of verifying that the EUT behaves according to the expected behaviour (for instance the EUT 
behaviour shows that it receives the expected message). 

• A configure corresponds to an action to modify the EUT configuration. 

• A check ensures the receipt of protocol messages on reference points, with valid content. This "check" event 
type corresponds to the method called 'interoperability testing with conformance check'. 
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4.2 Test Description naming convention 



Table 1 : TD naming convention 



TD/<root>/<gr>/<nn> 






<root> = root 


COAP 


Constrained Application Protocol 




M2M COAP 


CoAP Binding for IVI2M 


<gr> = group 


CORE 


Core protocol 




LINK 


CoRE Link Format 




BLOCK 


Blockwise transfers 




OBS 


Observing Ressources 


<nn> = sequential number 




01 to 99 



5 Test Description Summary 

5.1 CoAP Binding for I\/I2I\/I REST Resources 

Table 2: CoAP Binding for M2M REST Resources 



1 


TD M2M COAP 01 


M2M DA registers to its local SCL via an applicationCreateRequest (CoAP POST) 


2 


TD M2M COAP 02 


IVI2M DA retrieves application resource via an applicationRetrieveRequest (CoAP GET) 


3 


TD_M2M_COAP_03 


M2M DA updates attribute in application resource via an applicationUpdateRequest 
(CoAP PUT) 


4 


TD_M2M_COAP_04 


IVI2M DA creates a subscription to application resource via subscriptionCreateRequest 
(CoAP POST) 


5 


TD M2M COAP 05 


I\/I2M GSCL sends notification(s) via subscriptionNotifyRequest (CoAP POST) 


6 


TD M2M COAP 06 


M2M DA cancels subscription via an subscriptionDeleteRequest (CoAP DELETE) 


7 


TD_M2M_COAP_07 


M2M DA de-registers by deleting application resource via an applicationDeleteRequest 
(CoAP DELETE) 


8 


TD_M2M_COAP_08 


Handle contentlnstanceRetrieveRequest with targetID containing several path 
segments 


9 


TD M2M COAP 09 


Handle contentlnstanceRetrieveRequest with targetID containing several query options 


10 


TD M2M COAP 10 


Handle contentlnstanceRetrieveRequest with targetID using partial addressing 


11 


TD M2M COAP 11 


I\/I2M DA registration with Announcement 


12 


TD M2M COAP 12 


IVI2M NA multi-hop resource retrieval using Proxy-URI (CoAP proxy) 


13 


TD M2M COAP 13 


IVI2M NA multi-hop resource retrieval using m2mPocs (I\/I2M proxy) 
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5.2 



Additional CoAP 



Tables: CoAP Tests 



1 


TD COAP CORE 01 


Perform GET transaction (CON mode) 


2 


TD COAP CORE 02 


Perform POST transaction (CON mode) 


3 


TD COAP CORE 03 


Perform PUT transaction (CON mode) 


4 


TD COAP CORE 04 


Perform DELETE transaction (CON mode) 


5 


TD COAP CORE 05 


Perform GET transaction (NON mode) 


6 


TD COAP CORE 06 


Perform POST transaction (NON mode) 


7 


TD COAP CORE 07 


Perform PUT transaction (NON mode) 


8 


TD COAP CORE 08 


Perform DELETE transaction (NON mode) 


9 


TD COAP CORE 09 


Perform GET transaction with delayed response (CON mode, no piggybacl<) 


10 


TD COAP CORE 10 


Perform GET transaction containing Tol<en option (CON mode) 


11 


TD COAP CORE 11 


Perform GET transaction containing tol<en option witli a separate response (CON mode) 


12 


TD COAP CORE 12 


Perform GET transaction not containing Tol<en option (CON mode) 


13 


TD COAP CORE 13 


Perform GET transaction containing several URI-Path options (CON mode) 


14 


TD COAP CORE 14 


Perform GET transaction containing several URI-Ouery options (CON mode) 


15 


TD COAP CORE 15 


Perform GET transaction (CON mode, piggybacl<ed response) in a lossy context 


16 


TD COAP CORE 16 


Perform GET transaction (CON mode, delayed response) in a lossy context 


17 


TD COAP CORE 17 


Perform GET transaction with a separate response (NON mode) 


18 


TD_C0AP_C0RE_18 


Perform POST transaction with responses containing several Location-Path options (CON 
mode) 


19 


TD_C0AP_C0RE_19 


Perform POST transaction with responses containing several Location-Query options 
(CON mode) 


20 


TD COAP CORE 20 


Perform GET transaction containing the Accept option (CON mode) 


21 


TD COAP CORE 21 


Perform GET transaction containing the ETag option (CON mode) 


22 


TD_COAP_CORE_22 


Perform GET transaction with responses containing the ETag option and requests 
containing the If-Match option (CON mode) 


23 


TD COAP CORE 23 


Perform PUT transaction with responses containing the If-None-Match option (CON mode) 


24 


TD_COAP_CORE_24 


Perform POST transaction with responses containing several Location-Path options 
(Reverse Proxy in CON mode) 


25 


TD_COAP_CORE_25 


Perform POST transaction with responses containing several Location- Ouery (Reverse 
proxy) 


26 


TD COAP CORE 26 


Perform GET transaction containing the Accept option (CON mode) (Reverse proxy) 


27 


TD_COAP_CORE_27 


Perform GET transaction with responses containing the ETag option and requests 
containing the If-Match option (CON mode) (Reverse proxy) 


28 


TD_COAP_CORE_28 


Perform GET transaction with responses containing the ETag option and requests 
containing the If-None-Match option (CON mode) (Reverse proxy) 


11 
9 


TD_COAP_CORE_29 


Perform GET transaction with responses containing the Max-Age option (Reverse proxy) 


30 


TD COAP LINK 01 


Access to well-known interface for resource discovery 


31 


TD COAP LINK 02 


Use filtered requests for limiting discovery results 


32 


TD COAP LINK 03 


Handle empty prefix value strings 


33 


TD COAP LINK 04 


Filter discovery results in presence of multiple rt attributes 


34 


TD COAP LINK 05 


Filter discovery results using if attribute and prefix value strings 


35 


TD COAP LINK 06 


Filter discovery results using sz attribute and prefix value strings 


36 


TD COAP LINK 07 


Filter discovery results using href attribute and complete value strings 


37 


TD COAP LINK 08 


Filter discovery results using href attribute and prefix value strings 


38 


TD COAP LINK 09 


Arrange link descriptions hierarchically 


39 


TD COAP LINK 10 


Handle an alternate link 


40 


TD COAP BLOCK 01 


Handle GET blockwise transfer for large resource (early negotiation) 


41 


TD COAP BLOCK 02 


Handle GET blockwise transfer for large resource (late negotiation) 


42 


TD COAP BLOCK 03 


Handle PUT blockwise transfer for large resource 


43 


TD COAP BLOCK 04 


Handle POST blockwise transfer for large resource 


44 


TD COAP OBS 01 


Handle resource observation with CON messages 


45 


TD COAP OBS 02 


Handle resource observation with NON messages 


46 


TD COAP OBS 03 


Stop resource observation 


47 


TD COAP OBS 04 


Client detection of deregistration (Max-Age) 


48 


TD COAP OBS 05 


Server detection of deregistration (client OFF) 


49 


TD COAP OBS 06 


Server detection of deregistration (explicit RST) 


50 


TD COAP OBS 07 


Server cleans the observers list on DELETE 


51 


TD COAP OBS 08 


Server cleans the observers list when observed resource content-format changes 


52 


TD COAP OBS 09 


Update of the observed resource 
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6 Basic Configuration 

6.1 Resources offered by servers under test 

In order to ease test setup and execution, CoAP servers are requested to support the following resources and primitives: 

Table 4: M2M Primitives 



Subject 


Primitive 


Application management 


applicationCreateRequest / Response 


applicationRetrieveRequest / Response 


applicationUpdateRequest / Response 


applicationDeleteRequest / Response 


Subscription management 


subscriptionCreateRequest / Response 


subscriptionNotifyRequest / Response 


subscriptionDeleteRequest / Response 


Content management 


contentlnstanceCreateRequest / Response 


containerCreateRequest/Response 


contentlnstanceRetrieveRequest / Response 


Announcement management 


applicationAnncCreateRequest / Response 


PoC management 


m2mPocCreateRequest / Response 
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Table 5: Examples of M2M Resources Representations 



M2M Primitive 


Resource 
name 


Resource Representation 


applicationCreateRequest 


<app> 


<?xml version="l .0"?> 

<tns : application 

xmlns : tns="http ://uri.etsi. org/m2m" 

tns :id="app"/> 


applicationCreateResponse 


<app> 


<?xml version="l .0"?> 

<tns : application 

xmlns :tns="http://uri.etsi.org/m2m" tns: id="app"> 

<tns:expirationTime>2 012-1 0- 
25T13 : 13 : 04</tns :expirationTime> 
</tns : application> 


applicationRetrieveResponse 


<app> 


<?xml version="l .0"?> 

<tns : application 

xmlns :tns="http://uri.etsi. org/m2m" tns : id="app"> 

<tns : applicationStatus>ONLINE</tns : applicationSta 
tus> 

<tns:expirationTime>2 012-ll- 
19T18:39:05</tns: expirationTime> 

<tns : lastModif iedTime>2012-ll- 
12T1 9 : 59 : 05</tns : lastModif iedTime> 

<tns : containersRef erence> 

/ gs dBase /applicat ions /app/ containers 
</tns : containersRef erence> 
<tns :groupsReference> 

/gs dBase /applicat ions /app/ groups 
</tns : groupsRef erence> 
<tns : accessRightsRef erence> 

/gs dBase /applicat ions/ app/ accessRights 
</tns : accessRightsRef erence> 
<tns : subscriptionsRef erence>/ 

/gs dBase /applicat ions /app/ subscript ions 

</tns : subscriptionsReference> 
</tns : application> 


applicationUpdateRequest 


<app> 


<?xml version="l . 0"?> 
<tns : application 
xmlns :tns="http://uri.etsi.org/m2m"> 

<tns : aPoOcoap: //DA_IP_Address :Port</tns : aPoO 
</tns : application> 


applicationUpdateResponse 


<app> 


<?xml version="l .0"?> 

<tns : application 

xmlns :tns="http://uri.etsi. org/m2m"> 

<tns :expirationTime>2 012-1 0- 
2 5T13 : 13:04</tns:expirationTime> 
</tns : application> 


applicationCreateRequest 


<app_ann> 


<?xml version="l .0"?> 

<tns : application 

xmlns :tns="http://uri.etsi.org/m2m" 

tns : id="app_ann"> 

<tns : announceTo> 

<tns : activated>true</tns : activated> 

</tns : announceTo> 

<tns : aPoOcoap: //DA_IP_Address :Port</tns : aPoO 
</tns : applicat ion> 
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M2M Primitive 


Resource 
name 


Resource Representation 


applicationCreateResponse 


<app_ann> 


<tns : application 

xmlns : tns="http : //uri . etsi . org/m2m" 

tns : id="app_ann "> 

<tns : expirat ionTime>2 12-10- 
2 5T13 : 13:04</tns:expirationTime> 
</tns : application> 


subscriptionCreateRequest 


<sub> 


<?xml version="l .0"?> 

<tns : subscription 

xmlns :tns="http://uri.etsi.org/m2m" tns:id=" sub"> 

<tns : contact>coap : //DA_IP_Addr :Port/da_notif </tns 

: contact> 

</tns : subscription> 


subscriptionCreateResponse 


<sub> 


<?xml version="l .0"?> 

<tns : subscription 

xmlns :tns="http://uri.etsi.org/m2m" tns: id="sub 

"> 

<tns : expirat ionTime>2 012 -10- 
2 5T13 : 13:04</tns:expirationTime> 
</tns : subscription> 


subscriptionNotifyRequest 


<sub> 


<?xml version="l .0"?> 

<tns : notify xmlns :tns="http://uri.etsi. org/m2m"> 

<statusCode>l</statusCode> 

<representation> 

base64Binary encoded representation of 
application resource 

</representation> 

<subscriptionRef erence> 

coap: //GW_IP_Addr : P ort / gwOl/applicat ions /app/ subs 
criptions/sub 

</subscriptionRef erence> 
</tns : notifY> 


subscriptionNotifyResponse 


<sub> 


<?xml version="l .0"?> 

<tns : notify xmlns :tns="http://uri.etsi.org/m2m"> 

<statusCode>l</statusCode> 
</tns : notifY> 


containerCreateRequest 


<containerl> 


<?xml version="l .0"?> 

<tns : container 

xmlns :tns="http://uri.etsi.org/m2m" 

tns : id="containerl"/> 


containerCreateResponse 


<containerl> 


<?xml version="l .0"?> 

<tns: container 

xmlns :tns="http://uri.etsi.org/m2m" 

tns : id="containerl"/> 


contentlnstanceCreateRequest 


<test> 


<?xml version="l .0"?> 

<tns : content In stance 

xmlns :tns="http://uri.etsi.org/m2m"> 

<tns : content> 

<tns : text Content >content</ tns : textContent> 

</tns : content> 
</tns : content Instance> 


contentlnstanceCreateResponse 


<test> 


<?xml version="l .0"?> 

<tns : content In stance 

xmlns :tns="http://uri.etsi.org/m2m" 

tns:id="test"/> 
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Table 6: Resources offered by CoAP Servers 



Resource name 


Description 


Used in 


/test 


Default test resource 


TD COAP CORE 01 
TD COAP CORE 02 
TD COAP CORE 03 
TD COAP CORE 04 
TD COAP CORE 05 
TD COAP CORE 06 
TD COAP CORE 07 
TD COAP CORE 08 
TD COAP CORE 10 
TD COAP CORE 11 
TD COAP CORE 14 
TD COAP CORE 18 
TD COAP CORE 22 
TD COAP LINK 08 
TD COAP LINK 10 


/validate 


Resource which varies 


TD COAP CORE 21 
TD COAP CORE 27 
TD COAP CORE 29 


/createl 


Resource which does not exist yet (to perform atomic 
PUT) 


TD_COAP_CORE_23 


/create2 


Resource which does not exist yet 


TD COAP CORE 24 


/creates 


Resource which does not exist yet 


TD COAP CORE 28 


/segl/seg2/seg3 


Long path resource 


TD COAP CORE 12 


/locationl/location2/lo 
cation3 


Location path resource 


TD COAP CORE 18 
TD COAP CORE 24 


/location-query 


Resource accepting location query parameters 


TD COAP CORE 19 
TD COAP CORE 25 


/query 


Resource accepting query parameters 


TD COAP CORE 13 


/separate 


Resource which cannot be served immediately and 
which cannot be acknowledged in a piggy-backed 
way 


TD COAP CORE 09 
TD COAP CORE 15 
TD COAP CORE 16 


/large 


Large resource 


TD COAP BLOCK 01 
TD COAP BLOCK 02 


/large-update 


Large resource that can be updated using PUT 
method 


TD_COAP_BLOCK_03 


/large-create 


Large resource that can be created using POST 
method 


TD_COAP_BLOCK_04 


/obs 


Observable resource which changes every 5 seconds 
and for which the server is configured to send 
confirmable (CON) notifications 


TD COAP OBS 01 
TD COAP OBS 03 
TD COAP OBS 04 
TD COAP OBS 05 
TD COAP OBS 06 
TD COAP OBS 07 
TD COAP OBS 08 
TD COAP OBS 09 


/obs-non 


Observable resource which changes every 5 seconds 
and for which the server is configured to send non- 
confirmable (NON) notifications 


TD_COAP_OBS_02 


/ .well-known/core 


Core Link Format 


TD COAP LINK 01 
TD COAP LINK 02 
TD COAP LINK 03 
TD COAP LINK 04 
TD COAP LINK 05 
TD COAP LINK 06 
TD COAP LINK 07 
TD COAP LINK 08 
TD COAP LINK 09 
TD COAP LINK 10 


/mult i- format 


Resource that exists in different content formats 
(text/plain utf8 and application/xml) 


TD COAP CORE 20 
TD COAP CORE 26 


/linkl 


Link test resource 


TD COAP LINK 07 
TD COAP LINK 08 


/link2 


Link test resource 


TD COAP LINK 07 
TD COAP LINK 08 
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Resource name 


Description 


Used in 


/links 


Link test resource 


TD COAP LINK 07 
TD COAP LINK 08 


/path 


Hierarchical link description entry 


TD COAP LINK 09 


/path/subl 


Hierarchical link description sub-resource 


TD COAP LINK 09 


/path/sub2 


Hierarchical link description sub-resource 


TD COAP LINK 09 


/path/sub3 


Hierarchical link description sub-resource 


TD COAP LINK 09 


/alternate 


Alternate 


TD COAP LINK 10 



Note on resource sizes: 

• Ressources used in TD_COAP_CORE tests should not exceed 64 bytes 

• Large resources used in TD_COAP_BLOCK tests shall not exceed 2 048 bytes 

• TD_COAP_LINK tests may require usage of Block options with some implementations 



6.2 



M2M Access Control 



M2M Access control is not being used. Hence there is no primitive attribute 'requestingEntity' being mapped to any 
CoAP query parameter. 

6.3 aPoc Re-Targeting Procedure 

When M2M DA registers to its GSCL it can: 

• either use the aPoc Re-Targeting mechanism; 

• or create and update contentlnstance resource on the GSCL. 

As a consequence, when the GSCL receives a resource retrieve request, it will: 

• either forward the request to DA; 

• or reply directly to the request itself. 



6.4 CoAP settings 



Unless stated otherwise, the following settings shall be applied: 

• Each equipment under test shall be configured with a unicast address 

• Client cache shall be cleaned up after each test 

• Use of ETag option shall be avoided, but implementation should be prepared to handle it 

• Use of Token shall be avoided, but implementation should be prepared to handle it 

• Use of Piggybacked responses shall be preferred 



Test Configurations 



This clause defines the different test configurations. 
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7.1 Basic M2M CoAP (M2M_CFG_01) 




dia 




Figure 1 



7.2 M2M CoAP Multihop (M2M_CFG_02) 
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7.3 Basic CoAP 1 (CoAP_CFG_01 ) 
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Figure 3: Basic One-2-One CoAP client/server Configuration 
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7.4 CoAP in lossy context (CoAP_CFG_02) 
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Figure 4: Basic One-2-One CoAP client/server Configuration in lossy context 

The Gateway emulates a lossy medium between the client and the server. It does not implement the CoAP protocol 
itself (in other terms it is not a CoAP proxy), but works at the transport layer. It provides two features: 

• It performs NAT-style UDP port redirections towards the server (thus the client contacts the gateway and is 
transparently redirected towards the server) 

• It randomly drops packets that are forwarded between the client and the server 

7.5 Test Configuration 3 (CoAP_CFG_03) 
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Figure 5: Basic One-2-One CoAP proxy/server Configuration 

The reverse proxy shown in the Figure 5 is assumed as CoAP/CoAP proxy. Test operator includes an interface (it can 
be a CoAP client) that creates the stimulus to initiate the tests for reverse proxy. 

More clearly, there exist two methods to create the stimulus for reverse proxy: 

1) Reverse proxy can provide a direct interface to create and launch the stimulus 

2) A CoAP client can be connected to reverse proxy to create and launch the stimulus for the tests 
In the both cases, reverse proxy and client equally act as point of observation. 
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8 Test Descriptions 

8.1 CoAP Binding for I\/I2I\/I REST Resources 
8.1.1 ApplicationCreateRequest 



Interoperability Test Description 


Identifier: 


TD M2M COAP 01 


Objective: 


l\/12l\/l DA registers to its local SCL via an applicationCreateRequest (CoAP POST) 


Configuration: 


M2M CFG 01 




[5], clauses 10.8.2, Annex D 
6 , clause 9.3.2.8 




Pre-test 
conditions: 


void 


1 


Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


IVI2M DA is requested to send a 
applicationCreateRequest (CoAP POST) 


2 


Check (dia) 


Sent POST request contains: 

• Code = 2(P0ST) 

• Uri-Path: <sclBase> 

• Uri-Path: applications 

• Payload: application resource <app> to be created 

• Content Type option 


3 


Check (dia) 


SCL sends response containing: 

• Code = 65(2.01 Created) 

• Location-Path: <sclBase> 

• Location-Path: applications 

• Location-Path: <app> 

• The same IVIessage ID as that of the previous 
request 


4 


Verify (dia) 


IVI2M DA indicates successful operation 



8.1.2 ApplicationRetrieveRequest 



Interoperability Test Description | 


Identifier: 


TD M2M COAP 02 


Objective: 


M2M DA retrieves application resource via an applicationRetrieveRequest (CoAP GET) 


Configuration: 


M2M CFG 01 


References: 


[5], clauses 10.8.3, Annex D 
[6], clause 9.3.2.8 


1 


Pre-test 
conditions: 


• DA has created an Application resource <app> on SCL 


1 


Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


IVI2M DA is requested to send a applicationRetrieveRequest 
(CoAP GET) 


2 


Check (dia) 


Sent GET request contains 

• Code =1 (GET) 

• Uri-Path: <sclBase> 

• Uri-Path: applications 

• Uri-Path: <app> 

• Content Format option 


3 


Check (dia) 


SCL sends response containing: 

• Code = 69(2.05 Content) 

• The same Message ID as that of the previous request 

• Payload: application resource for <app> 


4 


Verify (dia) 


IVI2M DA indicates successful operation 
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8.1.3 ApplicationUpdateRequest 



Interoperability Test Description 


Identifier: 


TD M2M COAP 03 


Objective: 


IVI2IVI DA updates attribute in application resource via an applicationUpdateRequest 
(CoAP PUT) 


Configuration: 


M2M CFG 01 


References: 


[5], clauses 10.8.4, Annex D 
6 , clause 9.3.2.8 




Pre-test 
conditions: 


• DA has created an Application resource <app> on SCL 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


M2M DA is requested to send a 
applicationUpdateRequest (CoAP PUT) 


2 


Check (dla) 


Sent PUT request contains 

• Code = 3 (PUT) 

• Uri-Path: <sclBase> 

• Uri-Path: applications 

• Uri-Path: <app> 

• Payload: modified application resource 

• Content Format option 


3 


Check (dla) 


SCL sends response containing: 

• Code = 68 (2.04 Changed) 

• The same IVIessage ID as that of the previous 
request 


4 


Verify (dla) 


IV12M DA indicates successful operation 



8.1.4 SubscriptionCreateRequest 



Interoperability Test Description 


Identifier: 


TD M2M COAP 04 


Objective: 


M2M DA creates a subscription to application resource via SubscriptionCreateRequest 
(CoAP POST) 


Configuration: 


M2M CFG 01 


References: 


[5], clauses 10.25.2, Annex D 
[6], clause 9.3.2.8.19 




Pre-test 
conditions: 


• DA has created an Application resource <app> on SCL 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


M2M DA is requested to send a 
SubscriptionCreateRequest (CoAP POST) 


2 


Check (dla) 


Sent POST request contains 

• Code = 2(P0ST) 

• Uri-Path: <sclBase> 

• Uri-Path: applications 

• Uri-Path: <app> 

• Uri-Path: subscriptions 

• Payload: subscription resource <sub> to be created 

• Content Format option 


3 


Check (dla) 


SCL sends response containing: 

• Code = 65(2.01 Created) 

• Location-Path: <sclBase> 

• Location-Path: applications 

• Location-Path: <app> 

• Location-Path: subscriptions 

• Location-Path: <sub> 

• The same IVIessage ID as that of the previous 
request 


4 


Verify (dla) 


IVI2M DA indicates successful operation 
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8.1.5 SubscriptionNotifyRequest 



Interoperability Test Description 


Identifier: 


ID M2M COAP 05 


Objective: 


M2M GSCL sends notification(s) via SubscriptionNotifyRequest (CoAP POST) 


Configuration: 


M2M CFG 01 


References: 


[5], clauses 10.25.7, Annex D 
6 , clause 9.3.2.8.19 




Pre-test 
conditions: 


• DA has created an Application resource <app> on SCL 

• DA has created subscription <sub> to <app> on SCL 




Test Sequence: 


Step 


Type 


Description 




1 


Stimulus 


I\/I2M DA is requested to send a 
applicationUpdateRequest (CoAP PUT) 


2 


Check (dla) 


Sent PUT request contains 

• Code = 3 (PUT) 

• Uri-Path: <sclBase> 

• Uri-Path: applications 

• Uri-Path: <app> 

• Payload: modified application resource 

• Content Format option 


3 


Check (dla) 


Server sends response containing: 

• Code = 68 (2.04 Changed) 

• The same Message ID as that of the previous 
request 


4 


Verify (dla) 


M2M DA indicates successful operation 


5 


Verify (dla) 


SCL sends SubscriptionNotifyRequest (CoAP POST) 


6 


Check (dla) 


Sent POST request contains 

• Type = (CON) 

• Code = 2(P0ST) 

• Uri-Path: contact attribute of <sub> 

• Payload: notify structure for <app> 

• Content Format option 


7 


Verify (dla) 


M2M DA sends subscriptionNotifyResponse 


8 


Check (dla) 


M2M DA sends response containing: 

• Code = 65(2.01 Created) 

• The same IVIessage ID as that of the previous 
request 


9 


Verify (dla) 


IVI2M DA indicates updated value for <app> 
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8.1.6 SubscriptionDeleteRequest 



Interoperability Test Description 


Identifier: 


TD M2M COAP 06 


Objective: 


IVI2M DA cancels subscription via an SubscriptionDeleteRequest (CoAP DELETE) 


Configuration: 


M2M CFG 01 


References: 


[5], clauses 10.25.5, Annex D 
6 , clause 9.3.2.8.19 




Pre-test 
conditions: 


• DA has created an Application resource <app> on SCL 

• DA has created subscription <sub> to <app> on SCL 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


I\/I2M DA is requested to send a 
SubscriptionDeleteRequest (CoAP DELETE) 


2 


Check (dia) 


Sent POST request contains 

• Code = 4 (DELETE) 

• Uri-Path: <sclBase> 

• Uri-Path: applications 

• Uri-Path: <app> 

• Uri-Path: subscriptions 

• Uri-Path: <sub> 


3 


Check (dia) 


SCL sends response containing: 

• Code = 66(2.02 Deleted) 

• The same Message ID as that of the previous 
request 


4 


Verify (dia) 


M2M DA indicates successful operation 



8.1.7 ApplicationDeleteRequest 



Interoperability Test Description 


Identifier: 


TD M2M COAP 07 


Objective: 


IVI2M DA de-registers by deleting application resource via an applicationDeleteRequest 
(CoAP DELETE) 


Configuration: 


M2M CFG 01 


References: 


[5], clauses 10.8.5, Annex D 
[6], clause 9.3.2.8 




Pre-test 
conditions: 


• DA has created an Application resource <app> on SCL 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


M2M DA is requested to send a 
applicationDeleteRequest (CoAP DELETE) 


2 


Check (dia) 


Sent POST request contains 

• Code = 4 (DELETE) 

• Uri-Path: <sclBase> 

• Uri-Path: applications 

• Uri-Path: <app> 


3 


Check (dia) 


Server sends response containing: 

• Code = 66 (2.02 Deleted) 

• The same IVIessage ID as that of the previous 
request 


4 


Verify (dia) 


IVI2M DA indicates successful operation 
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8.1 .8 TargetID containing several patin segments 



Interoperability Test Description 


identifier: 


TD M2M COAP 08 


Objective: 


Handle contentlnstanceRetrieveRequest with targetID containing several path 
segments 


Configuration: 


M2M CFG 01 


References: 


[5], clauses 10.19.3, Annex D 
6 , clause 9.3.2.15 




Pre-test 
conditions: 


• DA has created an Application resource <app> on SCL 

• DA has created container <container1 > on SCL via containerCreateRequest 

• DA has created container <container2> on SCL via containerCreateRequest 

• DA has created a resource /<containerl>/<contentinstances>/<test> 
on SCL via contentlnstanceCreateRequest 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


M2M DA is requested to send a 
contentlnstanceRetrieveRequest (CoAP GET) on 
resource 
<containerl>/<contentInstances>/<test> 


2 


Check (dla) 


Sent GET request contains 

• Code =1 (GET) 

• Uri-Path: <sclBase> 

• Uri-Path: applications 

• Uri-Path: <app> 

• Uri-Path: <container1> 

• Uri-Path: <container2> 

• Uri-Path: <test> 

• Content Format option 


3 


Check (dla) 


SCL sends response containing: 

• Code = 69(2.05 Content) 

• The same Message ID as that of the previous 
request 


4 


Verify (dla) 


M2M DA indicates successful operation 
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8.1 .9 TargetID containing several query options 



Interoperability Test Description 


identifier: 


TD M2M COAP 09 


Objective: 


Handle contentlnstanceRetrieveRequest with targetID containing several query options 


Configuration: 


M2M CFG 01 


References: 


[5], clauses 10.19.3, Annex D 
6 , clause 9.3.2.15 




Pre-test 
conditions: 


• DA has created an Application resource <app> on SCL 

• DA has created a collection of resources <collec> with filter criteria (criterial , 
criteria2) on SCL using contentlnstancesCreateRequest 

• DA has created several resources in this collection via 
contentlnstantCreateRequest 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


I\/I2M DA is requested to send a 
contentlnstanceRetrieveRequest (CoAP GET) on 
resource <collec> with filter criteria (criterial , criteria2) 


2 


Check (dia) 


Sent GET request contains 

• Code =1 (GET) 

• Uri-Path: <sclBase> 

• Uri-Path: applications 

• Uri-Path: <app> 

• Uri-Path: <collec> 

• Uri-Query: criterial , valuel 

• Uri-Query: criteria2, value2 

• Content Format option 


3 


Check (dia) 


SCL sends response containing: 

• Code = 69(2.05 Content) 

• The same IVIessage ID as that of the previous 
request 


4 


Verify (dia) 


IV12M DA indicates successful operation 
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8.1 .1 TargetID using partial addressing 



Interoperability Test Description 


Identifier: 


TD M2M COAP 10 


Objective: 


Handle contentlnstanceRetrieveRequest with targetID using partial addressing 


Configuration: 


M2M CFG 01 


References: 


[5], clauses 10.19.3, Annex D 
[6], clause 9.3.2.1 5 




Pre-test 
conditions: 


• DA has created an Application resource <app> on SCL 

• DA has created container <container1 > on SCL via containerCreateRequest 

• DA has created a XML resource /<container1>/<xml-partial> containing 
<partial> attribute on SCL via contentlnstanceCreateRequest 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


I\/I2M DA is requested to send a 
contentlnstanceRetrieveRequest (CoAP GET) on 
attribute <partial> in resource <xml-partial> 


2 


Check (dia) 


Sent GET request contains 

• Code =1 (GET) 

• Uri-Path: <sclBase> 

• Uri-Path: applications 

• Uri-Path: <app> 

• Uri-Path: <container1> 

• Uri-Path: <xml-partial> 

• Uri-Path: <partial> 

• Content Format option 


3 


Check (dla) 


SCL sends response containing: 

• Code = 69(2.05 Content) 

• The same IVIessage ID as that of the previous 
request 


4 


Verify (dla) 


IVI2M DA indicates successful operation 
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8.1.11 Announcement 



Interoperability Test Description 


identifier: 


ID M2M COAP 11 


Objective: 


M2M DA registration with Announcement 


Configuration: 


M2M CFG 02 


References: 


[5], clauses 10.9.2, Annex D 
6 , clause 9.3.2.28 






Pre-test 


• GSCL has registered to NSGL as <gscl> 


conditions: 








Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


I\/I2M DA is requested to send a 








applicationCreateRequest (CoAP POST) with 








AnnounceTo option activated 


2 


Check (dla) 


Sent POST request contains 








• Code = 2(P0ST) 








• Uri-Path: applications 








• Payload: application resource <app_ann> to be 








created 








• Content Format option 


3 


Check (dla) 


GSCL sends response containing: 








• Code = 65(2.01 Created) 








• Location-Path: <gsclBase> 








• Location-Path: applications 








• Location-Path: <app ann> 








• The same Message ID as that of the previous 








request 


4 


Verify (dla) 


M2M DA indicates successful operation 


5 


Verify (mid) 


IVI2M GSCL sends applicationAnncCreateRequest (CoAP 








POST) to M2M NSCL 


6 


Check (mid) 


Sent POST request contains 








• Code = 2(P0ST) 








• Uri-Path: scis 








• Uri-Path: <gscl> 








• Uri-Path: applications 








• Uri-Path: <app_ann>Annc 








• Payload: applicationAnnc resource 








<app ann>Annc to be created 








• Content Format option 


7 


Check (mid) 


NSCL sends response containing: 








• Code = 65(2.01 Created) 








• Location-Path: <nsclBase> 








• Location-Path: scis 








• Location-Path: <gscl> 








• Location-Path: applications 








• Location-Path: <app_ann>Annc 








• The same IVIessage ID as that of the previous 








request 


8 


Verify (mid) 


NSCL indicates announced resource <app ann>Annc 
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8.1 .12 Multihop retrieval using Proxy-Uri ar\6 aPoC 



Interoperability Test Description 


Identifier: 


TD M2M COAP 12 


Objective: 


IVI2IVI NA multi-hop resource retrieval using Proxy-URI (CoAP proxy) 


Configuration: 


M2M CFG 02 


References: 


[5], clauses 1 0. 1 9.3, Annex D 1 .5 
6 , clause 9.3.2.15 




Pre-test 
conditions: 


• DA has created an announceable Application resource <app_ann> on GSCL 

• GSCL has announced <app_ann> to NSCL 

• DA offers the resource /test 

• NA has discovered the resource /test offered by DA 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


M2M NA is requested to send a 
contentlnstanceRetrieveRequest (CoAP GET) to NSCL 
for resource /test on DA 


2 


Check (mla) 


Sent GET request contains 

• Code =1 (GET) 

• Proxy-Uri: 
coap://<gsclBase>/applications/<app_ann>/test 

• Content Format option 


3 


Verify (mid) 


NSCL proxies the request to GSCL 


4 


Check (mid) 


Proxied GET request contains 

• Code =1 (GET) 

• Uri-Path: applications 

• Uri-Path: <app ann> 

• Uri-Path: test 

• Content Format option 


5 


Check (mid) 


GSCL sends response containing: 

• Code = 69(2.05 Content) 

• The same IVIessage ID as that of the previous 
request 

• Payload: content of resource /test 


6 


Verify (mla) 


NSCL proxies the response to NA 


7 


Check (mla) 


Proxied response contains: 

• Code = 69(2.05 Content) 

• The same IVIessage ID as that of the previous 
request 

• Payload: content of resource /test 


8 


Verify (mla) 


M2M NA indicates successful operation 
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8.1 .13 Multihop retrieval using m2mPocs 



Interoperability Test Description 



Identifier: 



TD M2M COAP 12 



Objective: 



M2M NA multi-hop resource retrieval using m2mPocs (M2M proxy) 



Configuration: 



IVI2M CFG 02 



References: 



[5], clauses 10.19.3, Annex D 

[6], clause 7.3, 9.2.1 .9, 9.2.3.4, 9.2.3.24, 9.2.3.25, 9.3.2.21 



Pre-test 
conditions: 



DA has created a Application resource <app > on GSCL 

DA offers the resource <test> 

GSCL has created an m2mPoc <test_poc> on NSOL for resource <test> 



Test Sequence: 



Step 



Type 



Stimulus 



Check (mia) 



Verify (mid) 



Check (mid) 



Check (mid) 



Verify (mia) 



Check (mia) 



Verify (mia) 



Description 



M2M NA is requested to send a 
contentlnstanceRetrieveRequest (CoAP GET) to NSCL 
for resource <test> 



Sent GET request contains 
Code= 1(GET) 
Uri-Path: <gscl> 
Uri-Path: applications 
Uri-Path: <app> 
Uri-Path: <container1> 
Uri-Path: <test> 
Content Format option 



NSCL proxies the request to GSCL using m2mpoc 
information 



Proxied GET request contains 

• Code =1 (GET) 

• Uri-Path: <gscl> 

• Uri-Path: applications 

• Uri-Path: <app> 

• Uri-Path: <container1> 
Uri-Path: <test>Content Format option 



GSCL sends response containing: 

• Code = 69(2.05 Content) 

• The same Message ID as that of the previous 
request 

• Payload: content of resource <test> 



NSCL proxies the response to NA 



Proxied response contains: 

• Code = 69(2.05 Content) 

• The same IVIessage ID as that of the previous 
request 

• Payload: content of resource <test> 



M2M NA indicates successful operation 
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8.2 



Additional CoAP 



8.2.1 CoAP protocol 



Interoperability Test Description 


Identifier: 


ID COAP CORE 01 


Objective: 


Perform GET transaction (CON mode) 


Configuration: 


CoAP CFG 01 


References: 


[1], clauses 5.8.1,1.2,2.1,2.2,3.1 




Pre-test 
conditions: 


• Server offers the resource /test with resource content Is not empty that handles 
GET with an arbitrary payload 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to send a GET request with: 
• Type = O(CON) 
. Code =1 (GET) 


2 


Check 


The request sent by the client contains: 
• Type=0 and Code=1 


3 


Check 


Server sends response containing: 

• Code = 69(2.05 Content) 

• The same Message ID as that of the request sent 
by the client 

• Content format option 


4 


Verify 


Client displays the received information 



Interoperability Test Description 


Identifier: 


TD COAP CORE 02 


Objective: 


Perform DELETE transaction (CON mode) 


Configuration: 


CoAP CFG 01 


References: 


[1], clauses 5.8.4, 1.2,2.1,2.2,3.1 




Pre-test 
conditions: 


• Server offers a /test resource that handles DELETE 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to send a DELETE request with: 

• Type = O(CON) 

• Code = 4(DELETE) 


2 


Check 


The request sent by the client contains: 
• Type=0 and Code=4 


3 


Check 


Server sends response containing: 

• Code = 66(2.02 Deleted) 

• The same Message ID as that of the request sent by 
the client 


4 


Verify 


Client displays the received information 
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Interoperability Test Description 


Identifier: 


ID COAP CORE 03 


Objective: 


Perform PUT transaction (CON mode) 


Configuration: 


CoAP CFG 01 


References: 


[1], clauses 5.8.3, 1.2,2.1,2.2,3.1 




Pre-test 
conditions: 


• Server offers already available resource / test or accepts creation of new 
resource on /test that handles PUT 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to send a PUT request with: 

• Type = O(CON) 
. Code = 3(PUT) 

• An arbitrary payload 

• Content format option 


2 


Check 


The request sent by the client contains: 
• Type=0 and Code=3 


3 


Verify 


Server displays received information 


4 


Check 


Server sends response containing: 

• Code = 68 (2.04 Changed) or 65 (2.01 Created) 

• The same IVIessage ID as that of the request sent by 
the client 


5 


Verify 


Client displays the received response 



Interoperability Test Description 


Identifier: 


TD COAP CORE 04 


Objective: 


Perform POST transaction (CON mode) 


Configuration: 


CoAP CFG 01 


References: 


[1], clauses 5.8.2, 1.2,2.1,2.2,3.1 




Pre-test 
conditions: 


• Server accepts creation of new resource on / test (resource does not exist yet) 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to send a POST request with: 

• Type = O(CON) 

. Code = 2(P0ST) 

• An arbitrary payload 

• Content format option 


2 


Check 


The request sent by the client contains: 
• Type=0 and Code=2 


3 


Verify 


Server displays received information 


4 


Check 


Server sends response containing: 

• Code = 65(2.01 Created) or 68 (2.04 changed) 

• The same IVIessage ID as that of the request sent by 
the client 


5 


Verify 


Client displays the received response 
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Interoperability Test Description 


Identifier: 


ID COAP CORE 05 


Objective: 


Perform GET transaction (NON mode) 


Configuration: 


CoAP CFG 01 


References: 


[1], clauses 5.8.1, 5.2.3 




Pre-test 
conditions: 


• Server offers a /test resource with resource content is not empty that handles 
GET 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to send a GET request with: 

• Type =1 (NON) 

• Code =1 (GET) 


2 


Check 


The request sent by the client contains: 
• Type=1 and Code=1 


3 


Check 


Server sends response containing: 

• Type =1 (NON) 

• Code= 69(2.05 Content) 

• Content format option 


4 


Verify 


Client displays the received information 



Interoperability Test Description 


Identifier: 


TD COAP CORE 06 


Objective: 


Perform DELETE transaction (NON mode) 


Configuration: 


CoAP CFG 01 


References: 


[1], clauses 5.8.4, 5.2.3 




Pre-test 
conditions: 


• Server offers a /test resource that handles DELETE 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to send a DELETE request with: 

• Type =1 (NON) 

• Code = 4(DELETE) 


2 


Check 


The request sent by the client contains: 
• Type=1 and Code=4 


3 


Check 


Server sends response containing: 

• Type =1 (NON) 

• Code = 66(2.02 Deleted) 


4 


Verify 


Client displays the received information 



Interoperability Test Description 


Identifier: 


TD COAP CORE 07 


Objective: 


Perform PUT transaction (NON mode) 


Configuration: 


CoAP CFG 01 


References: 


[1], 5.8.3, 5.2.3 




Pre-test 
conditions: 


• Server offers a /test resource that handles PUT 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to send a PUT request with: 

• Type =1 (NON) 
. Code = 3(PUT) 

• An arbitrary payload 

• Content format option 


2 


Check 


The request sent by the client contains: 
• Type=1 and Code=3 


3 


Verify 


Server displays the received information 


4 


Check 


Server sends response containing: 

• Type =1 (NON) 

• Code = 68 (2.04 Changed) or 65 (2.01 Created) 


5 


Verify 


Client displays the received response 
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Interoperability Test Description 


Identifier: 


ID COAP CORE 08 


Objective: 


Perform POST transaction (NON mode) 


Configuration: 


CoAP CFG 01 


References: 


[1], clauses 5.8.2, 5.2.3 




Pre-test 
conditions: 


• Server accepts creation of new resource on /test (resource does not exist yet) 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to send a POST request with: 

• Type =1 (NON) 

• Code = 2(P0ST) 

• An arbitrary payload 

• Content format option 


2 


Checl< 


The request sent by the client contains: 
• Type=1 and Code=2 


3 


Verify 


Server displays the received information 


4 


Checl< 


Server sends response containing: 

• Type =1 (NON) 

• Code = 65(2.01 Created) or 68 (2.04 changed) 


5 


Verify 


Client displays the received response 



Interoperability Test Description 


Identifier: 


TD COAP CORE 09 


Objective: 


Perform GET transaction with separate response (CON mode, no piggyback) 


Configuration: 


CoAP CFG 01 


References: 


[1], clauses 5.8.1, 5.2.2 




Pre-test 
conditions: 


• Server offers a resource /separate which cannot be served immediately and 
which cannot be acknowledged in a piggybacked way. 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to send a confirmable GET request to 
server's resource 




2 


Check 


The request sent by the client contains: 
. Type = (CON) 

• Code = 1 (GET) 

• Client generated IVIessage ID 




3 


Check 


Server sends response containing: 

• Type = 2 (ACK) 

• Code = 

• Same message ID as in the request sent by the client 

• empty Payload 




4 


Check 


Server sends response containing: 

• Type = (CON) 

• Code = 69 (2.05 content) 

• Server generated Message ID 

• Not empty Payload 

• Content format option 




5 


Check 


Client sends response containing: 
. Type = 2 (ACK) 

• Code = 

• Same message ID as in the response sent by the 
server in step 4 

• empty Payload 




6 


Verify 


Client displays the response 


NOTE: Steps 3 and 4 may occur out-of-order. 
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Interoperability Test Description 


Identifier: 


ID COAP CORE 10 


Objective: 


Perform GET transaction containing Tol<en option (CON mode) 


Configuration: 


CoAP CFG 01 


References: 


[1], clauses 2.2, 5.8.1,5.10.1 




Pre-test 
conditions: 


• Server offers a /test resource with resource content is not empty that handles 
GET 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to send a GET request to server's 
resource including Token option 




2 


Check 


The request sent by the client contains: 

• Type = (CON) 
. Code = 1 (GET) 

• Option Type = Token 

• Token value = a value generated by the client 

• Length of the token should be between 1 to 8 B 




3 


Check 


Server sends response containing: 

• Code = 69 (2.05 content) 

• Length of the token should be between 1 to 8 B 

• Token = the same value as in the request sent by the 
client 

• Not empty Payload 

• Content format option 




4 


Verify 


Client displays the response 



Interoperability Test Description 


Identifier: 


TD COAP CORE 11 


Objective: 


Perform GET transaction containing token option with a separate response (CON 
mode) 


Configuration: 


CoAP CFG 01 


References: 


[1], clauses 2.2, 5.2.2, 5.8.1 




Pre-test 
conditions: 


• Server offers a resource /separate which cannot be served immediately. 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to send a GET request to server's 
resource including Token option 




2 


Check 


The request sent by the client contains: 

• Type = (CON) 

• Code = 1 (GET) 

• Option Type = Token 

• Token value = a value generated by the client 

• Length of the token should be between 1 to 8 B 




3 


Check 


Server sends acknowledgement containing: 
. Type = 2 (ACK) 

• Code = (Empty) 

• same IVIessage-ld as in step 2 

• empty Payload 




4 


Check 


Server sends response containing: 
. Type = (CON) 

• Code = 69 (2.05 content) 

• Length of the token should be between 1 to 8 B 

• Token value = the same value as in the request sent 
by the client in step 2 

• Not empty Payload 




5 


Check 


Client sends acknowledgement containing: 

• Type = 2 (ACK) 

• Code = (Empty) 

• same Message-Id as in step 4 

• empty Payload 




6 


Verify 


Client displays the response 
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Interoperability Test Description 


Identifier: 


ID COAP CORE 12 


Objective: 


Perform GET transaction not containing Token option (CON mode) 


Configuration: 


CoAP CFG 01 


References: 


[1], clauses 2.2, .8.1,5.10.1 




Pre-test 
conditions: 


• Server offers a /test resource with resource content is not empty that handles 
GET 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to send a confirmable GET request not 
containing Token option to server's resource 




2 


Check 


The request sent by the client contains: 

• Type = (CON) 

• Code = 1 (GET) 

• No Token option 




3 


Check 


Server sends response containing: 

• Code = 69 (2.05 content) 

• No Token option 

• Not empty Payload 

• Content format option 




4 


Verify 


Client displays the response 



Interoperability Test Description 


Identifier: 


TD COAP CORE 13 


Objective: 


Perform GET transaction containing several URI-Path options (CON mode) 


Configuration: 


CoAP CFG 01 


References: 


[1], clauses 5.4.5, 5.10.2, 6.5 




Pre-test 
conditions: 


• Server offers a /seg1/seg2/seg3 resource with resource content is not empty 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to send a confirmable GET request to 
server's resource 




2 


Check 


The request sent by the client contains: 
. Type = (CON) 

• Code = 1 (GET) 

• Option type = URI-Path (one for each path segment), 
not containing 7' symbol 




3 


Check 


Server sends response containing: 

• Code = 69 (2.05 content) 

• Not empty Payload 

• Content format option 




4 


Verify 


Client displays the response 
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Interoperability Test Description 


Identifier: 


ID COAP CORE 14 


Objective: 


Perform GET transaction containing several URI-Query options (CON mode) 


Configuration: 


CoAP CFG 01 


References: 


[1], clauses 5.4.5, 5.10.2, 6.5 




Pre-test 
conditions: 


• Server offers a /query resource with resource content is not empty 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to send a confirmable GET request with 
three Query parameters (e.g. ?first=1&second=2&third=3) to 
the server's resource 




2 


Check 


The request sent by the client contains: 

• Type = (CON) 

• Code = 1 (GET) 

• Option type = URI-Query (More than one query 
parameter) 




3 


Check 


Server sends response containing: 

• Type = (CON) or 2 (ACK) 

• Code = 69 (2.05 content) 

• Not empty Payload Content format option 




4 


Verify 


Client displays the response 



Interoperability Test Description 


Identifier: 


TD COAP CORE 15 


Objective: 


Perform GET transaction (CON mode, piggybacked response) in a lossy context 


Configuration: 


CoAP CFG 02 


References: 


[1], clauses 4.4.1, 5.2.1, 5.8.1 




Pre-test 
conditions: 


• Gateway is introduced and configured to produce packet losses 

• Server offers a /test resource with resource content is not empty that can handle 
GET 


Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to send a confirmable GET request to 
server's resource 


2 


Check 


Sent request shall contain: 

• Type = 

• Code = 1 

• Client generated IVIessage ID 


3 


Check 


Server sends response containing: 

• Type = 2 (ACK) 

• Code = 69 (2.05 content) 

• Not empty Payload 

• Content format option 


4 


Verify 


Client displays the response 


5 


Check 


Repeat steps 1-4 until at least one of the following actions has 
been observed: 

• One dropped request 

• One dropped response 




6 


Verify 


For each case mentioned in step 5: 
Observe that retransmission is launched 
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Interoperability Test Description 


Identifier: 


ID COAP CORE 16 


Objective: 


Perform GET transaction (CON mode, delayed response) in a lossy context 


Configuration: 


CoAP CFG 02 


References: 


[1], clauses 4.4.1, 5.2.2, 5.8.1 




Pre-test 
conditions: 


• Gateway is introduced and configured to produce packet losses 

• Server offers a /separate resource which cannot be served immediately and 
which cannot be acknowledged in a piggybacked way. 


Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to send a confirmable GET request to 
server's resource 




2 


Check 


The requested sent by the client contains: 

• Type = 

• Code = 1 

• a message ID generated by the client 




3 


Check 


Server sends response containing: 

• Type = 2 (ACK) 

• message ID is the same as in the request 

• empty Payload 




4 


Check 


Server sends response containing: 

• Type = (CON) 

• Code = 69 (2.05 content) 

• Not empty Payload 

• Content format option 




5 


Check 


Client sends response containing: 

• Type = 2 (ACK) 

• message ID is the same as in the response of step 3 

• empty Payload 




6 


Verify 


Client displays the response 




7 


Check 


Repeat steps 1-6 until at least one of the following actions has 
been observed: 

• One dropped request 

• One dropped request ACK 

• One dropped response 

• One dropped response ACK and its retransmission 




8 


Verify 


For each case mentioned in step 7: 
Observe that retransmission is launched 
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Interoperability Test Description 


Identifier: 


ID COAP CORE 17 


Objective: 


Perform GET transaction with a separate response (NON mode) 


Configuration: 


CoAP CFG 01 


References: 


[1], clauses 2.2, 5.2.2, 5.8.1 




Pre-test 
conditions: 


• Server offers a resource /separate whicli cannot be served immediately. 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to send a non-confirmable GET request to 
server's resource 




2 


Check 


The request sent by the client contains: 
. Type = 1 (NON) 

• Code = 1 (GET) 

• A message ID generated by the Client 




3 


Check 


Server DOES NOT send response containing: 
. Type = 2 (ACK) 

• Same message ID as in the request in step 2 

• empty Payload 




4 


Check 


Server sends response containing: 
. Type = 1 (NON) 

• Code = 69 (2.05 content) 

• Not empty Payload d 

• Content format option 




5 


Verify 


Client displays the response 
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Interoperability Test Description 


Identifier: 


ID COAP CORE 18 


Objective: 


Perform POST transaction with responses containing several Location-Path options 
(CON mode) 


Configuration: 


CoAP CFG 01 


References: 


[1], clauses 5.8.1, 5.10.8, 5.9.1.1 




Pre-test 
conditions: 


• Server accepts creation of new resource on /test and the created resource is 
located at /location1/location2/location3 (resource does not exist yet) 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to send a confirmable POST request to 
server's resource 




2 


Check 


The request sent by the client contains: 
. Type = (CON 

• Code = 2 (POST) 

• An arbitrary payload 

• Content-format option 




3 


Check 


Server sends response containing: 

• Code = 65 (2.01 created) 

• Option type = Location-Path (one for each segment) 

• Option values shall contain "locationi ", "location2" & 
"locations" without containing any '/' 




4 


Verify 


Client displays the response 



Interoperability Test Description 


Identifier: 


TD COAP CORE 19 


Objective: 


Perform POST transaction with responses containing several Location-Query options 
(CON mode) 


Configuration: 


CoAP CFG 01 


References: 


[1], clauses 5.8.1, 5.10.8, 5.9.1.1 




Pre-test 
conditions: 


• Server accepts creation of new resource on uri /location-query, the location of 
the created resource contains two query parameters ?first=1&second=2 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to send a confirmable POST request to 
server's resource 




2 


Check 


The request sent by the client contains: 

• Type = (CON) 

• Code = 2 (POST) 

• An arbitrary payload 

• Content-format option 




3 


Check 


Server sends response containing: 

• Code = 65 (2.01 created) 

• Two options whose type is Location-Query 

• The first option contains first=1 

• The second option contains second=2 




4 


Verify 


Client displays the response 
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Interoperability Test Description 


Identifier: 


ID COAP CORE 20 


Objective: 


Perform GET transaction containing the Accept option (CON mode) 


Configuration: 


CoAP CFG 01 


References: 


[1], clauses 5.8.1, 5.10.5, 5.10.4 




Pre-test 
conditions: 


Server should provide a resource /multi-format which exists in two formats; 

• text/plain;charset=utf-8 

• application/xml 




Test Sequence: Step Type Description 


Part A: client requests a resource in text format 




1 


Stimulus 


Client is requested to send a confirmable GET request to 
server's resource 




2 


Check 


The request sent request by the client contains: 
. Type = (CON) 

• Code = 1 (GET) 

• Option: type = Accept, value = (text/plain; 
charset=utf-8) 




3 


Check 


Server sends response containing: 

• Code = 69 (2.05 content) 

• Option type = Content-Format, value = 
(text/plain ;charset=utf-8) 

• Payload = Content of the requested resource in 
text/plain;charset=utf-8 format 




4 


Verify 


Client displays the response 


Part B: client requests a resource in xml format 




5 


Stimulus 


Client is requested to send a confirmable GET request to 
server's resource 




6 


Check 


The request sent by the client contains: 
. Type = (CON) 

• Code = 1 (GET) 

• Option: type = Accept, value = 41 (application/xml) 




7 


Check 


Server sends response containing: 

• Code = 69 (2.05 content) 

• Option: type = Content-Format, value = 41 
(application/xml) 

• Payload = Content of the requested resource in 
application/xml format 




8 


Verify 


Client displays the response 
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Interoperability Test Description 


Identifier: 


ID COAP CORE 21 


Objective: 


Perform GET transaction containing the ETag option (CON mode) 


Configuration: 


CoAP CFG 01 


References: 


[1], clauses 5.8.1, 5.10.7, 5.10.10, 12.1.12 




Pre-test 
conditions: 


Server should offer a /validate resource which vary in time 
Client & server supports ETag option 
The Client 's cache has been purged 




Test Sequence: Step Type Description 


Part A: Verifying that client cache is empty 




1 


Stimulus 


Client is requested to send a confirmable GET request to 
server's resource 




2 


Check 


The request sent request by the client contains: 
. Type = (CON) 

• Code = 1 (GET) 

• No ETag option 




3 


Check 


Server sends response containing: 

• Code = 69 (2.05 content) 

• Option type = ETag 

• Option value = an arbitrary ETag value 

• Not empty Payload 




4 


Verify 


Client displays the response 


Part B: Verifying client cache entry is still valid 




5 


Stimulus 


Client is requested to send s confirmable GET request to 
server's resource so as to check if the resource was updated 




6 


Check 


The request sent by the client contains: 

• Type = (CON) 

• Code = 1 (GET) 

• Option Type=ETag 

• Option value=the ETag value received in step 3 




7 


Check 


Server sends response containing: 

• Code = 67 (2.03 Valid) 

• Option type = ETag 

• Option value = the ETag value sent in step 3 

• An empty payload 




8 


Verify 


Client displays the response 


Part C: Verifying that client cache entry is no longer valid 




9 


Stimulus 


Update the content of the server's resource from a CoAP 
client 




10 


Stimulus 


Client is requested to send a confirmable GET request to 
server's resource so as to check if the resource was updated 




11 


Check 


The request sent by the client contains: 
. Type = (CON) 

• Code = 1 (GET) 

• Option Type=ETag 

• Option value=the ETag value received in step 3 




12 


Check 


Server sends response containing: 

• Code = 69 (2.05 Content) 

• Option type = ETag 

• Option value = an arbitrary ETag value which differs 
from the ETag sent in step 3 

• The payload of the requested resource, which should 
be different from the payload in step 3 




13 


Verify 


Client displays the response 
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Interoperability Test Description 


Identifier: 


ID COAP CORE 22 


Objective: 


Perform GET transaction with responses containing tlie ETag option and requests 
containing the If-IVIatch option (CON mode) 


Configuration: 


CoAP CFG 01 


References: 


[1], clauses 5.8.1, 5.10.7, 5.10.9, 12.1.12 




Pre-test 
conditions: 


• Server should offer a /validate resource 

• Client & server supports ETag and If-IVIatch option 

• The Client 's cache has been purged 




Test Sequence: Step Type Description 


Preamble: client gets the resource 




1 


Stimulus 


Client is requested to send a confirmable GET request to 
server's resource 




2 


Check 


The request sent by the client contains: 

• Type = (CON) 

• Code = 1 (GET) 




3 


Check 


Server sends response containing: 

• Code = 69 (2.05 content) 

• Option type = ETag 

• Option value = an arbitrary Etag value 

• Not empty Payload 


Part A: single update 




4 


Stimulus 


Client is requested to send a confirmable PUT request to 
server's resource so as to perform an atomic update 




5 


Check 


The request sent by the client contains: 

• Type = (CON) 

• Code = 3 (PUT) 

• Option Type=lf-IVIatch 

• Option value=ETag value received in step 3 

• An arbitrary payload (which differs from the payload 
received in step 3) 




6 


Check 


Server sends response containing: 
• Code = 68 (2.04 Changed) 




7 


Verify 


Client displays the response and the server changed its 
resource 


Part B: concurrent updates 




8 


Stimulus 


Client is requested to send a confirmable GET request to 
server's resource 




9 


Check 


The request sent by the client contains: 

• Type = (CON) 

• Code = 1 (GET) 




10 


Check 


Server sends response containing: 

• Code = 69 (2.05 content) 

• Option type = ETag 

• Option value = an arbitrary Etag value which differs 
from the ETag sent in step 3 

• The Payload sent in step 5 




11 


Verify 


Client displays the response 




12 


Stimulus 


Update the content of the server's resource from a CoAP 
client 




13 


Stimulus 


Client is requested to send a confirmable PUT request to 
server's resource so as to perform an atomic update 
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14 


Check 


The request sent by the client contains: 

• Type = (CON) 

• Code = 3 (PUT) 

• Option Type=lf-l\/latch 

• Option value=ETag value received in step 10 

• An arbitrary payload (which differs from the previous 
payloads) 




15 


Check 


Server sends response containing: 

• Code = 140 (4.12 Precondition Failed) 




16 


Verify 


Client displays the response and the server did not update the 
content of the resource 



Interoperability Test Description 


Identifier: 


TD COAP CORE 23 


Objective: 


Perform PUT transaction containing the If-None-Match option (CON mode) 


Configuration: 


CoAP CFG 01 


References: 


[1], clauses 5.8.1, 5.10.7, 5.10.10, 12.1.12 




Pre-test 
conditions: 


Server should offer a /createl resource, which does not exist and which can be 

created by the client 

Client & server supports If-Non-Match 




Test Sequence: Step Type Description 


Part A: single creation 




1 


Stimulus 


Client is requested to send a confirmable PUT request to 
server's resource so as to atomically create the resource. 




2 


Check 


The request sent by the client contains: 
. Type = (CON) 

• Code = 3 (PUT) 

• Option Type=lf-None-l\/latch 

• An arbitrary payload 




3 


Check 


Server sends response containing: 
• Code = 65 (2.01 Created) 




4 


Verify 


Client displays the response and the server created a new 
resource 


Part B: concurrent creations 




5 


Stimulus 


Client is requested to send a confirmable PUT request to 
server's resource so as to atomically create the resource. 




6 


Check 


The request sent by the client contains: 

• Type = (CON) 
. Code = 3 (PUT) 

• Option Type=lf-None-Match 

• An arbitrary payload 




7 


Check 


Server sends response containing: 
• 140 (4.12 Precondition Failed) 




8 


Verify 


Client displays the response 
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Interoperability Test Description 


Identifier: 


ID COAP CORE 24 


Objective: 


Perform POST transaction with responses containing several Location-Path options 
(Reverse Proxy in CON mode) 


Configuration: 


CoAP CFG 03 


References: 


[1], clauses 5.8.1, 5.10.8, 5.9.1.1,8.2.2,8.2.1, 10.2.2, 11.2 




Pre-test 
conditions: 


• Proxy Is configured as a reverse-proxy for the server 

• Proxy's cache is cleared 

• Server accepts creation of new resource on /create2 and the created resource is 
located at /location1/location2/location3 (resource does not exist yet) 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to send a confirmable POST request to 
proxy 




2 


Check 


The POST sent by the client contains: 

• Type = (CON) 

• Code = 2 (POST) 

• An arbitrary payload 

• Content-format option 




3 


Check 


The Proxy forwards the POST request to server's resource 
and that it contains: 
. Type = (CON) 

• Code = 2 (POST) 

• An arbitrary payload 

• Content-format option 




4 


Check 


Server sends a response to the proxy containing: 

• Code = 65 (2.01 created) 

• Option type = Location-Path (one for each segment) 

• Option values shall contain "locationi ", "location2" & 
"locations" without contain any '/' 




5 


Check/ 


Observe that the Proxy forwards the response (in step 4) to 
client and check that the forwarded response contains: 

• Code = 65 (2.01 created) 

• Option type = Location-Path (one for each segment) 

• Option values shall contain "locationi ", "location2" & 
"locations" without contain any '/' 




6 


Verify 


Client displays the response 




7 


Verify 


Client interface returns the response 

2.01 created 

Location: coap://proxy/location1/location2/locationS 
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Interoperability Test Description 


Identifier: 


ID COAP CORE 25 


Objective: 


Perform POST transaction with responses containing several Location- Query option 
(Reverse proxy) 


Configuration: 


CoAP CFG 03 


References: 


[1], clauses 5.8.1, 5.10.8, 5.9.1.1, 8.2.2,8.2.1, 10.2.2, 11.2 




Pre-test 
conditions: 


• Proxy is configured as a reverse-proxy for the server 

• Proxy's cache is cleared 

• Server accepts creation of new resource on uri /location-query, the location of 
the created resource contains two query parameters ?first=1&second=2 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to send a confirmable POST request to 
proxy 




2 


Check 


Proxy receives the request from client & forwards it to server's 
resource 




3 


Check 


Forwarded request shall contain: 

• Type = (CON) 

• Code = 2 (POST) 

• An arbitrary payload 

• Content-format option 




4 


Check 


Server sends response to proxy containing: 

• Code = 65 (2.01 created) 

• Two options whose type is Location-Query 

• The first option contains flrst=1 

• The second option contains second=2 




5 


Check 


Proxy forwards the response to client 




6 


Check 


Client displays the message 




7 


Verify 


Client interface returns the response: 

2.01 created 

Location: coap://proxy/?first=1 &second=2 
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Interoperability Test Description 


Identifier: 


ID COAP CORE 26 


Objective: 


Perform GET transaction containing the Accept option (CON mode 


Configuration: 


CoAP CFG 03 


References: 


[1], clauses 5.8.1, 5.10.5, 5.10.4, 8.2.2, 8.2.1, 10.2.2, 11.2 




Pre-test 
conditions: 


• Proxy is configured as a reverse-proxy for the server 

• Proxy's cache is cleared 

• Server should provide a resource /multi-format which exists in two formats: 

text/plain ;charset=utf-8 
application/xml 




Test Sequence: Step Type Description 


Part A: client requests text format 




1 


Stimulus 


Client is requested to send a confirmable GET request to 
proxy 




2 


Check 


Proxy receives the request from client & forwards it to server's 
resource 




3 


Check 


Forwarded request shall contain: 
. Type = (CON) 

• Code = 1 (GET) 

• Option: type = Accept, value = (text/plain;charset=utf- 
8) 




4 


Check 


Server sends response containing: 

• Code = 69 (2.05 content) 

• Option: type = Content-Format, value = 
(text/plain ;charset=utf-8) 

• Payload = Content of the requested resource In 
text/plain;charset=utf-8 format 




5 


Check 


Proxy forwards the response to client 




6 


Verify 


Client receives & displays the response 




7 


Check 


Response contains: 

• Code = 69 (2.05 content) 

• Option: type = Content-Format, value = 
(text/plain ;charset=utf-8) 

• Payload = Content of the requested resource in 
text/plain;charset=utf-8 format 


Part B: client requests xml format 




8 


Stimulus 


Client is requested to send a confirmable GET request to 
Proxy 




9 


Check 


Proxy forwards the request to server 




10 


Check 


Sent request shall contain: 
. Type = (CON) 

• Code = 1 (GET) 

• Option: type = Accept, value = 41 (application/xml) 




11 


Check 


Server sends response containing: 

• Code = 69 (2.05 content) 

• Option: type = Content-Format, value = 41 
(application/xml) 

• Payload = Content of the requested resource In 
application/xml format 




12 


Check 


Proxy forwards the response to client 




13 


Verify 


Client receives & displays the response 




14 


Check 


Client displays the response received: 

• Code = 69 (2.05 content) 

• Option: type = Content-Format, value = 41 
(application/xml) 

• Payload = Content of the requested resource In 
application/xml format 
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Interoperability Test Description 


Identifier: 


ID COAP CORE 27 


Objective: 


Perform GET transaction with responses containing tlie ETag option and requests 
containing the If-IVIatch option (CON mode) 


Configuration: 


CoAP CFG 03 


References: 


[1], clauses 5.8.1, 5.10.7, 5.10.9, 12.1.12,8.2.2,8.2.1, 10.2.2, 11.2 




Pre-test 
conditions: 


• Proxy is configured as a reverse-proxy for the server 

• Proxy's cache is cleared 

• Server should offer a /validate resource with resource content is not empty 

• Client & server supports ETag option and If-IVIatch option 




Test Sequence: Step Type Description 


Preamble: client gets the resource 




1 


Stimulus 


Client is requested to send a confirmable GET request to 
proxy 




2 


Check 


Proxy forwards the request to server 




3 


Check 


Forwarded request shall contain: 
. Type = (CON) 
• Code = 1 (GET) 




4 


Check 


Server sends response containing: 

Code = 69 (2.05 content) 

Option type = ETag 

Option value = an arbitrary ETag value 

Not empty payload 




5 


Check 


Proxy forwards the response to client 


Part A: single update 




6 


Stimulus 


Client is requested to send a confirmable PUT request to 
Proxy 




7 


Check 


Sent request shall contain: 

• Type = (CON) 
. Code = 3 (PUT) 

• Option Type=lf-Match 

• Option value=ETag value received in step 4 

• An arbitrary payload (which differs from the payload 
received in step 3) 




8 


Verify 


Proxy forwards the request to servers resource & server 
updates the resource 




9 


Check 


Server sends response containing: 

• Code = 68 (2.04 Changed) 

• Option type = ETag 

• Option value = an arbitrary ETag value which differs 
from the ETag received in step 4 




10 


Check 


Proxy forwards the response to client 




11 


Check 


Forwarded response contains: 

• Code = 68 (2.04 Changed) 

• Option type = ETag 

• Option value = same ETag value found in step 8 




12 


Verify 


Client displays the response 


Part B: concurrent updates 




13 


Stimulus 


Update the content of the server's resource from a CoAP 
client 




14 


Stimulus 


Client is requested to send s confirmable PUT request to 
proxy so as to perform an atomic update 




15 


Check 


Sent request shall contain: 

• Type = (CON) 

• Code = 3 (PUT) 

• Option Type=lf-l\/latch 

• Option value=ETag value received in step 8 

• An arbitrary payload (which differs from the previous 
payloads) 




16 


Check 


Proxy forwards the request to server's resource 
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17 


Check 


Sent request shall contain: 

• Type = (CON) 

• Code = 3 (PUT) 

• Option Type=lf-Match 

• Option value=same ETag value found in step 14 

• An arbitrary payload (which differs from the previous 
payloads) 




18 


Check 


Server sends response containing: 

• Code = 140 (4.12 Precondition Failed) 




19 


Verify 


Proxy forwards the response to client 




20 


Check 


Response contains: 

• Code = 140 (4.12 Precondition Failed) 




21 


Verify 


Client displays the response 



Interoperability Test Description 


Identifier: 


TD COAP CORE 28 


Objective: 


Perform GET transaction with responses containing the ETag option and requests 
containing the If-None-IVIatch option (CON mode) (Reverse proxy) 


Configuration: 


CoAP CFG 03 


References: 


[1], clauses 5.8.1, 5.10.7, 5.10.10, 12.1.12, 8.2.2,8.2.1, 10.2.2, 11.2 




Pre-test 
conditions: 


• Proxy is configured as a reverse-proxy for the server 

• Proxy's cache is cleared 

• Server should offer a /creates resource, which does not exist and which can be 
created by the client 

• Client & server supports If-None-Match 




Test Sequence: Step Type Description 


Part A: single creation 




1 


Stimulus 


Client is requested to send a confirmable PUT request to 
proxy to atomically create resource in server 




2 


Check 


Proxy forwards the request to server 




3 


Check 


Forwarded t request shall contain: 

• Type = (CON) 

• Code = 3 (PUT) 

• Option Type=lf-None-Match 

• An arbitrary payload 




4 


Check 


Server sends response containing: 
• Code = 65 (2.01 Created) 




5 


Check 


Proxy forwards the response to client 




6 


Verify 


Client displays the response & and server created new 
resource 


Part B: concurrent creations 




5 


Stimulus 


Client is requested to send s confirmable PUT request to 
proxy to atomically create resource in server 




6 


Check 


Sent request shall contain: 

• Type = (CON) 

• Code = 3 (PUT) 

• Option Type=lf-Non-IVIatch 

• Option value=Received ETag value 




7 


Check 


Server sends response containing: 
• 140 (4.12 Precondition Failed) 




8 


Verify 


Proxy forwards the response to client 




9 


Check 


Response contains: 

• 140 (4.12 Precondition Failed) 




10 


Verify 


Client displays the response 
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Interoperability Test Description 


Identifier: 


ID COAP CORE 29 


Objective: 


Perform GET transaction with responses containing the Max-Age option (Reverse 
proxy) 


Configuration: 


CoAP CFG 03 


References: 


[1], clauses 5.8.1, 5.10.6, 5.9.1.3, 5.9.1.5, 8.2.2, 8.2.1, 10.2.2, 11.2 




Pre-test 
conditions: 


• Proxy offers a cache 

• Proxy is configured as a reverse-proxy for the server 

• Servers resource vary in time and supports Max-Age option 

• Proxy's cache is cleared 

• Server offers a resource /validate that varies in time, with a Max-Age set to 30 s 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


A confirmable GET request is sent to Proxy from Client 




2 


Check 


Proxy Sends request containing: 

• Type = (CON) 

• Code = 1 (GET) 




3 


Check 


Server sends response containing: 

• Code = 69 (2.05 Content) 

• Option type = ETag 

• Option value = ETag value 

• Option type = Max-age 

• Option value 

• Not empty Payload 




4 


Verify 


Proxy forwards response to client 




5 


Stimulus 


A confirmable GET request is sent to proxy from Client before 
Max- Age expires 




6 


Check 


Proxy dos not forward any request to the server 




7 


Check 


Proxy sends response to client 




8 


Verify 


Response contains: 

• Option type = Max-age 

• Option Value = new Max-age 

• Payload cached 



8.2.2 Core Link Format 



Interoperability Test Description 


Identifier: 


TD COAP LINK 01 


Objective: 


Access to well-known interface for resource discovery 


Configuration: 


CoAP CFG 01 


References: 


[2] 




Pre-test 
conditions: 


Client and server supports CoRE Link Format 

Server supports /.well-known/core resource and the CoRE Link Format 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to retrieve Server's list of resource 


2 


Check 


Client sends a GET request to Server for /.well-known/core 
resource 


3 


Check 


Server sends response containing: 

• Content-format option indicating 40 (application/link- 
format) 

• Code indicating 69 (2.05 content) 

• Payload indicating all the links available on Server 


4 


Verify 


Client displays the list of resources available on Server 
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Interoperability Test Description 


Identifier: 


TD COAP LINK 02 


Objective: 


Use filtered requests for limiting discovery results 


Configuration: 


CoAP CFG 01 


References: 


[2], clause 4.1 




Pre-test 
conditions: 


• Client supports CoRE Link Format 

• Server supports CoRE Link Format 

• Server offers different types of resources {Type1, Type2, ...; see note) 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to retrieve Server's list of resource of a 
specific type Type1 


2 


Check 


Client sends a GET request to Server for /.well-known/core 
resource containing URI-Query indicating "rUTypeV 


3 


Check 


Server sends response containing: 

• Content- format option indicating 40 (application/link- 
format) Payload indicating only the links of type Type1 
available on Server 


4 


Verify 


Client displays the list of resources of type Type1 available on 
Server 


NOTE: Type1, Type2, ... refer to real resource types available on Server and shall be extracted from 
Server's /.well-known/core resource. 



Interoperability Test Description 


Identifier: 


TD COAP LINK 03 


Objective: 


Handle empty prefix value strings 


Configuration: 


CoAP CFG 01 


References: 


[2], clause 4.1 §2 




Pre-test 
conditions: 


• Client supports Core Link Format 

• Server supports Core Link Format 

• Server offers different types of resources {Type1, Type2, ...; see note) 

• Server offers resources with no type (i.e. no rt attribute) 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to retrieve Server's list of resources 
matching an rt empty value 


2 


Check 


Client sends a GET request to Server for /.well-known/core 
resource containing URI-Query indicating rt="*" 


3 


Check 


Server sends response containing: 

• Content-format option indicating 40 (application/link- 
format) 

• Payload indicating only the links having an rt attribute 


4 


Verify 


Client displays the list of resources with rt attribute available 
on Server 


NOTE: Type1, Type2, ... refer to real resource types available on Server and shall be extracted from 
Server's /.well-known/core resource. 
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Interoperability Test Description 


Identifier: 


ID COAP LINK 04 


Objective: 


Filter discovery results in presence of multiple rt attributes 


Configuration: 


CoAP CFG 01 


References: 


[2], clauses 3.1,4.1 §2 




Pre-test 
conditions: 


• Client supports Core Link Format 

• Server supports Core Link Format 

• Server offers 4 groups of resources: 

1 . Resources with rt="Type1 Type2" 

2. Resources with rt="Type2 TypeS" 

3. Resources with rt="Type1 TypeS" 

4. Resources with rt="" 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to retrieve Server's list of resources of a 
specific type Type2 


2 


Check 


Client sends a GET request to Server for /.well-known/core 
resource containing URI-Query indicating rt="Type2" 


3 


Check 


Server sends response containing: 

• Content-format option indicating 40 (application/link- 
format) 

• Payload indicating only the links of groups 1 and 2 


4 


Verify 


Client displays the list of resources of type Type2 available on 
Server 



Interoperability Test Description 


Identifier: 


TD COAP LINK 05 


Objective: 


Filter discovery results using if attribute and prefix value strings 


Configuration: 


CoAP CFG 01 


References: 


[2], clauses 3.2, 4.1 §5 




Pre-test 
conditions: 


• Client supports Core Link Format 

• Server supports Core Link Format 

• Server offers 4 groups of resources: 

1. Resources with if="lf1" 

2. Resources with if="lf2" 

3. Resources with if="foo" 

4. Resources with no if attribute 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to retrieve Server's list of resources 
matching the interface description pattern "If*" 


2 


Check 


Client sends a GET request to Server for /.well-known/core 
resource containing URI-Query indicating if="lf*" 


3 


Check 


Server sends response containing: 

• Content-format option indicating 40 (application/link- 
format) 

• Payload indicating only the links of groups 1 and 2 


4 


Verify 


Client displays the retrieved list of resources 
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Interoperability Test Description 


Identifier: 


ID COAP LINK 06 


Objective: 


Filter discovery results using sz attribute and prefix value strings 


Configuration: 


CoAP CFG 01 


References: 


[2], clauses 3.3, 4.1 §5 




Pre-test 
conditions: 


• Client supports Core Link Format 

• Server supports Core Link Format 

• Server offers resource with sz attribute 

• Server offers resources with no sz attribute 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to retrieve Server's list of resources having 
a sz attribute 


2 


Check 


Client sends a GET request to Server for /.well-known/core 
resource containing URI-Query indicating sz="*" 


3 


Check 


Server sends response containing: 

• Content-format option indicating 40 (application/link- 
format) 

• Payload indicating only the links having a sz attribute 


4 


Verify 


Client displays the retrieved list of resources 



Interoperability Test Description 


Identifier: 


ID COAP LINK 07 


Objective: 


Filter discovery results using href attribute and complete value strings 


Configuration: 


CoAP CFG 01 


References: 


[2], clause 4.1 




Pre-test 
conditions: 


• Client supports Core Link Format 

• Server supports Core Link Format 

• Server offers resources /linkl /Iink2 and /Iink3 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to retrieve the link-value anchored at /linkl 


2 


Check 


Client sends a GET request to Server for /.well-known/core 
resource containing URI-Query indicating href="/link1" 


3 


Check 


Server sends response containing: 

• Content-format option indicating 40 (application/link- 
format) 

• Payload indicating only the link for /linkl 


4 


Verify 


Client displays the retrieved list of resources 



Interoperability Test Description 


Identifier: 


TD COAP LINK 08 


Objective: 


Filter discovery results using href attribute and prefix value strings 


Configuration: 


CoAP CFG 01 


References: 


[2], clause 4.1 




Pre-test 
conditions: 


• Client supports Core Link Format 

• Server supports Core Link Format 

• Server offers resources /linkl /Iink2 and /Iink3 

• Server offers resource /test 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to retrieve the link-value anchored at /link* 


2 


Check 


Client sends a GET request to Server for /.well-known/core 
resource containing URI-Query indicating href="/link*" 


3 


Check 


Server sends response containing: 

• Content-format option indicating 40 (application/link- 
format) 

• Payload indicating only the link matching /link* 


4 


Verify 


Client displays the retrieved list of resources 
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Interoperability Test Description 


Identifier: 


TD COAP LINK 09 


Objective: 


Arrange link descriptions hierarchically 


Configuration: 


CoAP CFG 01 


References: 


[2], clause 5 §4 




Pre-test 
conditions: 


• Client supports Core Link Format 

• Server supports Core Link Format 

• Server offers an entry located at /path with ct=40 

• Server offers sub-resources /path/sub1 , /path/sub2, ... (see note) 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to retrieve one of the sub-resources 


2 


Check 


Client sends a GET request to Server for /.well-known/core 
resource 


3 


Check 


Server sends response containing: 

• Content-format option indicating 40 (application/link- 
format) 

• Payload indicating the link description for /path 


4 


Check 


Client sends a GET request for /path to Server 


5 


Check 


Server sends response containing: 

Content-format option indicating 40 (application/link-format) 
Payload indicating the link description for /path/sub1 , 
/path/sub2, ... 




6 


Check 


Client sends a GET request for /path/sub1 




7 


Check 


Server sends 2.05 (Content) response. 
Payload contains /path/sub1 




8 


Verify 


Client displays the retrieved sub-resource. 


NOTE: /path/sub1 , /path/sub2, ... refer to real resources available on Server and shall be extracted from 
Server's /.well-known/core resource. 



Interoperability Test Description 


Identifier: 


TD COAP LINK 10 


Objective: 


Handle an alternate link 


Configuration: 


CoAP CFG 01 


References: 


[2], clause 5 §6 




Pre-test 
conditions: 


• Client supports Core Link Format 

• Server supports Core Link Format 

• Server offers resources /test and /alternate (see note) 

• Resource /alternate is anchored at /test (i.e. anchor="/test") with rel="alternate" 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to retrieve the resource /test using the 
alternate /alternate 


2 


Check 


Client sends a GET request to Server for /alternate 


3 


Check 


Server sends response containing the resource /test 


4 


Verify 


Client displays the response 


NOTE: /test and /alternate refer to a real resource and its alternate available on Server and shall be 
extracted from Server's /.well-known/core resource. 
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8.2.3 Blockwise transfers 



Identifier: 



TD COAP BLOCK 01 



Objective: 



Handle GET blockwise transfer for large resource (early negotiation) 



Configuration: 



CoAP CFG 01 



References: 



[4], clause 2.2 



Pre-test 
conditions: 



Client supports Block transfers 
Server supports Block transfers 
Server offers a large resource /large 
Client knows /large requires block transfer 



Test Sequence: 



Step 



(see note) 



(see note) 



Type 



Stimulus 



Check 



Check 



Check 



Check 



Check 



check 



Verify 



Description 



Client is requested to retrieve resource /large 



Client sends a GET request. The request optionally contains 
a Block2 option indicating: 

. NUIVI = 0; 

. M = 0; 

• SZX = the desired block size. 



Server sends 2.05 (Content) response with a Block2 option 
indicating: 

. NUIVI = 0; 

. M = 1; 

• SZX is less or equal to the desired block size indicated 
by the GET request. 
Payload size is 2^^^^^^ bytes 



Client send GET requests for further blocks indicating: 
• NUIVI = i where "i" is the block number of the current 

block; 
. IVI^O; 
» SZX is the SZX at step 3. 



Server sends 2.05 (Content) response containing Block2 
option indicating: 

• NUM = i where "i" is the block number used at step 4; 
. M = ^■, 

• SZX is the SZX at step 3. 

Payload size SHALL be 2^^^^^" bytes. 



Client send GET request for the last block indicating: 
• NUIVI = n where "n" is the last block number; 
. M = 0; 
» SZX is the SZX at step 3. 



Server sends 2.05 (Content) response with a Block2 option 
indicating: 

• NUIVI = n where "n" is the block number used at step 6; 
. M = 0; 

• SZX is the SZX at step 3. 

Payload size is lesser or equal to 2^^^^^^ bytes. 



Client displays the received information 



NOTE: Steps 4 and 5 are in a loop. 
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Identifier: 



TD COAP BLOCK 02 



Objective: 



Handle GET blockwise transfer for large resource (late negotiation) 



Configuration: 



CoAP CFG 01 



References: 



[4], clause 2.2 



Pre-test 
conditions: 



Client supports Block transfers 

Server supports Block transfers 

Server offers a large resource /large 

Client does not know /large requires block transfer 



Test Sequence: 



Step 



(see note) 



7 
(see note) 



10 



Type 



Stimulus 



Check 



Check 



Check 



Check 



Check 



Check 



Check 



Check 



Verify 



Description 



Client is requested to retrieve resource /large 



Client sends a GET request not containing Block2 option 



Server sends 2.05 (Content) response with a Block2 option 
indicating: 

. NUIVI = 0; 

. M = 1; 

• SZX = the proposed block size. 
Payload size is 2^^'^'"* bytes. 



Client switches to blockwise transfer mode and sends a GET 
request with a Block2 option indicating: 

• NUM is the next block number (should be equal to 

2SZX_in_step_4 - SZXJn_step_3> . 

. M = 0; 

» SZX is less or equals to SZX at step 3. 



Server sends 2.05 (Content) response with a Block2 option 
indicating: 

• NUIVI = k where "k" is the block number used at step 4; 
. M = 1; 

• SZX is the SZX at step 4. 

Payload size is 2^'^'^*'^ bytes. 



Client sends GET request for further blocks indicating: 
• NUIVI = i where "i" is the block number of the current 
block; 
. U = Q; 

SZX is the SZX at step 4. 



Server sends 2.05 (Content) response with a Block2 option 
indicating: 

• NUIVI = i where "i" is the block number used at step 6; 
. M = 1; 

• SZX is the SZX at step 4. 

Payload size is 2^^'^'"'' bytes. 



Client send GET request for the last block indicating: 
• NUIVI = n where "n" is the last block number; 
. IVI = 0; 

SZX is the SZX at step 4. 



Server sends 2.05 (Content) response with a Block2 option 
indicating: 

• NUIVI = n where "n" is the block number used at step 8; 
. M = 0; 

• SZX is the SZX at step 4. 

Payload size is lesser or equal to 2^^'^""". 



Client displays the received information 



NOTE: Steps 6 and 7 are in a loop. 
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Identifier: 


TD COAP BLOCK 03 


Objective: 


Handle PUT blockwise transfer for large resource 


Configuration: 


CoAP CFG 01 


References: 


[4], clause 2.2 




Pre-test 
conditions: 


• Client supports Block transfers 

• Server supports Block transfers 

• Server offers a large updatable resource /large-update 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to update resource /large-update on 
Server 


2 


check 


Client sends a PUT request containing Blockl option 
indicating: 

. NUM = 0; 

. M = 1; 

• SZX = the desired block size. 
Payload size is 2^^'^*" bytes. 


3 


Check 


Server sends 2.04 (Changed) response with a Blockl option 
indicating: 
. NUM = 0; 

• IVI = (stateless) or 1 (atomic); 

• SZX is less or equal to the SZX at step 2. 


4 
(see note) 


Check 


Client sends further requests containing Blockl option 

indicating: 

• NUIVI = i where "i" is the block number of the current 
block. If the server decreased the SZX parameter in 
step 3, then the client should adapt the block size 
accordingly and may resume the transfer from block id 

2Size_m_stepJ-sizejn_step_3 .^^j^^^ ^f ^|^^^ ^ ^ 

. M = 1; 

. SZX is the SZX at step 3. 
Payload size is 2^^'^*" bytes. 


5 
(see note) 


Check 


Server sends 2.04 (Changed) response containing Blockl 
option indicating: 

• NUIVI = i where "i" is the block number used at step 4; 

• M = (stateless) or 1 (atomic); 
. SZX is the SZX at step 3. 


6 


Check 


Client send PUT request containing the last block and 
indicating: 

• NUIVI = n where "n" is the last block number; 

. M = 0; 

. SZX is the SZX at step 3. 
Payload size is lesser or equal to 2^^'^*". 


7 


Check 


Server sends 2.04 (Changed) response with a Blockl option 
indicating: 

• NUIVI = n where "n" is the block number used at step 6; 

• M = 0; 

. SZX is the SZX at step 3. 


8 


Verify 


Server indicates presence of the complete updated resource 
/large-update 


NOTE: Steps 4 a 


id 5 are in a loop. 
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Identifier: 


TD COAP BLOCK 04 


Objective: 


Handle POST blockwise transfer for large resource 


Configuration: 


CoAP CFG 01 


References: 


[4], clause 2.2 




Pre-test 
conditions: 


• Client supports Block transfers 

• Server supports Block transfers 

• Server accepts creation of new resources on /large-create 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to create a new resource /large-create on 
Server 


2 


Check 


Client sends a POST request containing Blockl option 
indicating: 

. NUM = 0; 

. M = 1; 

• SZX = the desired block size. 
Payload size is 2^^'^""* bytes. 


3 


Check 


Server sends 2.01 (Created) response containing 
Blockl option indicating: 
. NUM = 0; 

• M = (stateless) or 1 (atomic); 

• SZX is less or equal to the SZX at step 2. 


4 
(see note) 


Check 


Client sends further requests containing 

Blockl option indicating: 

• NUIVI = i where "i" is the block number of the current 
block. If the server decreased the SZX parameter in 
step 3, then the client should adapt the block size 
accordingly and may resume the transfer from block id 

2Size_m_stepJ-sizejn_step_3 .^^j^^^ ^f ^|^^^ ^ ^ 

. M = 1; 

. SZX is the SZX at step 3. 
Payload size is 2^^'^*" bytes. 


5 
(see note) 


Check 


Server sends 2.01 (Created) response containing 
Blockl option indicating: 

• NUIVI = i where "i" is the block number used at step 4; 

. M = 1; 

. SZX is the SZX at step 3 


6 


Check 


Client send PUT request containing the last block and 
indicating: 

• NUIVI = n where "n" is the last block number; 

. M = 0; 

. SZX is the SZX at step 3. 
Payload size is lesser or equal to 2^^'^*". 


7 


Check 


Server sends 2.01 (Created) response containing Blockl 
option indicating: 

• NUIVI = n where "n" is the block number used at step 6; 

• M = 0; 

. SZX is the SZX at step 3. 


8 


Verify 


Server indicates presence of the complete new resource 
/large-create 


NOTE: Steps 4 a 


id 5 in a loop. 
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8.2.4 Observing Resources 



Interoperability Test Description 


Identifier: 


ID COAP OBS 01 


Objective: 


Handle resource observation with CON messages 


Configuration: 


CoAP CFG 01 


References: 


[4], clause 1.2, 




Pre-test 
conditions: 


• Client supports Observe option 

• Server supports Observe option 

• Server offers an observable resource /obs changing periodically (e.g. every 5 s) 
which produces confirmable notifications 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to send to the server a confirmable GET 
request with observe option for resource /obs 


2 


Check 


The request sent by client contains: 

• Type = (CON) 

• Code = 1 (GET) 

• Token value = a value generated by the client 

• Observe option = empty 


3 


Check 


Server sends the response containing: 
. Type = 2 (ACK) 

• Content-format of the resource /obs 

• Token value = same as one found in the step 2 

• Observe option with a sequence number 


4 
(see note) 


Check 


Server sends a notification containing: 

• Type = (CON) 

• Content-format = same as one found in the step 3 

• Token value = same as one found in the step 3 

• Observe option indicating increasing values 


5 


Verify 


Client displays the received information 


6 


Check 


Client sends an ACK 


NOTE: Steps 4-6 are in a loop. 



Interoperability Test Description 


Identifier: 


TD COAP OBS 02 


Objective: 


Handle resource observation with NON messages 


Configuration: 


CoAP CFG 01 


References: 


[4], clause 1.2 




Pre-test 
conditions: 


• Client supports Observe option 

• Server supports Observe option 

• Server offers an observable resource /obs-non changing periodically (e.g. every 
5 s) which produces non-confirmable notifications 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to send to the server a non-confirmable 
GET request with observe option for resource /obs 


2 


Check 


The request sent by client contains: 

• Type = 1 (NON) 

• Code = 1 (GET) 

• Token value = a value generated by the client 

• Observe option = empty 


3 
(see note) 


Check 


Server sends a notification containing: 

• Type = 1 (NON) 

• Content-format = the same for all notifications 

• Token value = same as one found in the step 2 

• Observe option indicating increasing values 


4 


Verify 


Client displays the received information 


NOTE: Steps 3-4 are in a loop. 
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Interoperability Test Description 


Identifier: 


TD COAP OBS 03 


Objective: 


Stop resource observation 


Configuration: 


CoAP CFG 01 


References: 


[4], clause 4.1 §3 




Pre-test 
conditions: 


• Client supports Observe option 

• Server supports Observe option 

• Server offers an observable resource /obs changing periodically (e.g. every 5 s) 
which produces confirmable notifications 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to send to the server a confirmable GET 
request with observe option for resource /obs 


2 


Check 


The request sent by client contains: 
. Type = (CON) 

• Code = 1 (GET) 

• Token value = a value generated by the client 

• Observe option = empty 


3 


Check 


Server sends the response containing: 
. Type = 2 (ACK) 

• Content-format of the resource /obs 

• Token value = same as one found in the step 2 

• Observe option with a sequence number 


4 

(see 

note 1 ) 


Check 


Server sends a notification containing: 

• Type = (CON) 

• Content-format = same as one found in the step 3 

• Token value = same as one found in the step 2 

• Observe option indicating increasing values 


5 


Check 


Client displays the received information 


6 


Check 


Client sends an ACK 


7 

(see 

note 2) 


Stimulus 


Client is requested to stop observing the resource /obs on the 
server 


8 


Check 


Client sends a request containing: 

• Type = (CON) 

• Code = 1 (GET) 

• Token value = a value generated by the client 

• DOES NOT contain observe option 


9 


Check 


Server sends response not containing Observe option 


10 


Verify 


Client displays the received information 


11 


Check 


Server does not send further response 


12 


Verify 


Client does not display updated information 


NOTE 1 : Steps 4-6 are in a loop. 

NOTE 2: Step 7-12 are asynchronous to the loop. 
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Interoperability Test Description 


Identifier: 


TD COAP OBS 04 


Objective: 


Client detection of deregistration (Max-Age) 


Configuration: 


CoAP CFG 01 


References: 


[4], clause 3.3 §4 




Pre-test 
conditions: 


• Client supports Observe option 

• Server supports Observe option 

• Server offers an observable resource /obs changing periodically (e.g. every 5 s) 
which produces confirmable notifications 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to send to the server a confirmable GET 
request with observe option for resource /obs 


2 


Check 


The request sent by client contains: 
. Type = (CON) 

• Code = 1 (GET) 

• Token value = a value generated by the client 

• Observe option = empty 


3 


Check 


Server sends the response containing: 
. Type = 2 (ACK) 

• Content-format of the resource /obs 

• Token value = same as one found in the step 2 

• Observe option with a sequence number 


4 
(note 1) 


Check 


Server sends a notification containing: 

• Type = (CON) 

• Content-format = same as one found in the step 3 

• Token value = same as one found in the step 2 

• Observe option indicating increasing values 


5 


Verify 


Client displays the received information 


6 


Check 


Client sends an ACK 


7 
(note 2) 


Stimulus 


Server is rebooted 


8 


Check 


Server does not send notifications 


9 


Verify 


Client does not display updated information 


10 


Verify 


After Max-Age expiration"* the client internally decides to send 
another GET request to the server with observe option for 
resource /obs 


11 


Verify 


Client sends a GET request to the server for resource /obs: 
. Type = (CON) 

• Code = 1 (GET) 

• Token value = a value generated by the client different 
from the token at step 2 

• Observe option = empty 


12 


Check 


Server sends the response containing: 

• Type = 2 (ACK) 

• Content-format of the resource /obs 

• Token value = same as one found in the step 1 1 

• Observe option with a sequence number 


13 
(note 3) 


Check 


Server sends a notification containing: 
. Type = (CON) 

• Content-format = same as one found in the step 1 2 

• Token value = same as one found in the step 1 1 

• Observe option indicating increasing values 


14 


Verify 


Client displays the received information 


15 


Check 


Client sends an ACK 


NOTE 1 : Steps 4-6 are in a loop. 
NOTE 2: Steps 7-9 are asynchronous to the loop 4-6. 
NOTE 3: Steps 13-15 are in a loop. 

NOTE 4: A new registration should be attempted after Max-Age -i- MAX LATENCY as recommended by 
[3]. MAX LATENCY is defined by [1] and set to 100 seconds. 
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Interoperability Test Description 


Identifier: 


TD COAP OBS 05 


Objective: 


Server detection of deregistration (client OFF) 


Configuration: 


CoAP CFG 01 


References: 


[4], clause 4.5 §2 




Pre-test 
conditions: 


• Client supports Observe option 

• Server supports Observe option 

• Server offers an observable resource /obs changing periodically (e.g. every 5 s) 
which produces confirmable notifications 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to send to the server a confirmable GET 
request with observe option for resource /obs 


2 


Check 


The request sent by client contains: 
. Type = (CON) 

• Code = 1 (GET) 

• Token value = a value generated by the client 

• Observe option = empty 


3 


Check 


Server sends the response containing: 
. Type = 2 (ACK) 

• Content-format of the resource /obs 

• Token value = same as one found in the step 2 

• Observe option with a sequence number 


4 
(note 1) 


Check 


Server sends a notification containing: 

• Type = (CON) 

• Content-format = same as one found in the step 3 

• Token value = same as one found in the step 2 

• Observe option indicating increasing values 


5 


Check 


Client displays the received information 


6 


Check 


Client sends an ACK 


7 
(note 2) 


Stimulus 


Client is switched off 


8 


Check 


Server's confirmable responses are not acknowledged 
Server's retransmissions have an updated Observe option 
value 


9 


Check 


Server should keep retransmitting the responses until at least 
IVIax-Age seconds after the first un-acknowledged response. 


NOTE 1 : Steps 4-6 are in a loop. 

NOTE 2: Steps 7-12 are asynchronous to the loop. 
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Interoperability Test Description 


Identifier: 


TD COAP OBS 06 


Objective: 


Server detection of deregistration (explicit RST) 


Configuration: 


CoAP CFG 01 


References: 


[4], clause 4.2 §5 




Pre-test 
conditions: 


• Client supports Observe option 

• Server supports Observe option 

• Server offers an observable resource /obs changing periodically (e.g. every 5 s) 
which produces confirmable notifications 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to send to the server a confirmable GET 
request with observe option for resource /obs 


2 


Check 


The request sent by client contains: 

• Type = (CON) 

• Code = 1 (GET) 

• Token value = a value generated by the client 

• Observe option = empty 


3 


Check 


Server sends the response containing: 
. Type = 2 (ACK) 

• Content-format of the resource /obs 

• Token value = same as one found in the step 2 

• Observe option with a sequence number 


4 
(notel) 


Check 


Server sends a notification containing: 
. Type = (CON) 

• Content-format = same as one found in the step 3 

• Token value = same as one found in the step 2 

• Observe option indicating increasing values 


5 


Check 


Client displays the received information 


6 


Check 


Client sends an ACK 


7 
(note 2) 


Stimulus 


Client is rebooted 


8 


Check 


Server is still sending notifications for the request In step 2. 
Notification contains: 

• Type = (CON) 

• Content-format = same as one found in the step 3 

• Token value = same as one found in the step 2 

• Observe option indicating increasing values 


9 


Verify 


Client discards response and does not display information 


10 


Check 


Client sends RST to Server 


11 


Verify 


Server does not send further response 


12 


Verify 


Client does not display further received information 


NOTE 1 : Steps 4-6 are in a loop. 

NOTE 2: Step 7-12 are asynchronous to the loop. 
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Interoperability Test Description 


Identifier: 


TD COAP OBS 07 


Objective: 


Server cleans the observers list on DELETE 


Configuration: 


CoAP CFG 01 


References: 


[4], clause 3.2 §4 




Pre-test 
conditions: 


• Client supports Observe option 

• Server supports Observe option 

• Server offers an observable resource /obs changing periodically (e.g. every 5 s) 
which produces confirmable notifications 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to send to the server a confirmable GET 
request with observe option for resource /obs 


2 


Check 


The request sent by client contains: 
. Type = (CON) 

• Code = 1 (GET) 

• Token value = a value generated by the client 

• Observe option = empty 


3 


Check 


Server sends the response containing: 
. Type = 2 (ACK) 

• Content-format of the resource /obs 

• Token value = same as one found in the step 2 

• Observe option with a sequence number 


4 
(note 1) 


Check 


Server sends a notification containing: 

• Type = (CON) 

• Content-format = same as one found in the step 3 

• Token value = same as one found in the step 2 

• Observe option indicating increasing values 


5 


Check 


Client displays the received information 


6 


Check 


Client sends an ACK 


7 
(note 2) 


Stimulus 


Delete the /obs resource of the server (either locally or by 
having another CoAP client perform a DELETE request) 


8 


Check 


Server sends a notification containing: 

• Type = (CON) 

• Code = 132 (4.04 NOT FOUND) 

• Token value = same as one found in the step 2 

• Observe option indicating increasing values 


9 


Verify 


Server does not send further responses 


10 


Verify 


Client does not display further received information 


NOTE 1 : Steps 4-6 are in a loop. 

NOTE 2: Step 7-1 are asynchronous to the loop. 
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Interoperability Test Description 


Identifier: 


TD COAP OBS 08 


Objective: 


Server cleans the observers list when observed resource content-format changes 


Configuration: 


CoAP CFG 01 


References: 


[4], clause 4.2 §3 




Pre-test 
conditions: 


• Client supports Observe option 

• Server supports Observe option 

• Server offers an observable resource /obs changing periodically (e.g. every 5 s) 
which produces confirmable notifications 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to send to the server a confirmable GET 
request with observe option for resource /obs 


2 


Check 


The request sent by client contains: 
. Type = (CON) 

• Code = 1 (GET) 

• Token value = a value generated by the client 

• Observe option = empty 


3 


Check 


Server sends the response containing: 
. Type = 2 (ACK) 

• Content-format of the resource /obs 

• Token value = same as one found in the step 2 
Observe option with a sequence number 


4 
(notel) 


Check 


Server sends a notification containing: 

• Type = (CON) 

• Content-format = same as one found in the step 3 

• Token value = same as one found in the step 2 

• Observe option indicating increasing values 


5 


Check 


Client displays the received information 


6 


Check 


Client sends an ACK 


7 
(note 2) 


Stimulus 


Update the /obs resource of the server's resource with a new 
payload having a different Content-Format (either locally or by 
having another CoAP client perform a DELETE request) 


8 


Check 


Server sends notification containing: 

• Type = (CON) 

• Code = 1 60 (5.00 INTERNAL SERVER ERROR) 

• Token value = same as one found in the step 2 

• Observe option indicating increasing values 


9 


Verify 


Server does not send further notifications 


10 


Verify 


Client does not display further received information 


NOTE 1 : Steps 4-6 are in a loop. 

NOTE 2: Step 7-10 are asynchronous to the loop. 
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Interoperability Test Description 


Identifier: 


TD COAP OBS 09 


Objective: 


Update of the observed resource 


Configuration: 


CoAP CFG 01 


References: 


[4], clause 4.2 §3 




Pre-test 
conditions: 


• Client supports Observe option 

• Server supports Observe option 

• Server offers an observable resource /obs changing periodically (e.g. every 5 s) 
which produces confirmable notifications 




Test Sequence: 


Step 


Type 


Description 


1 


Stimulus 


Client is requested to send to the server a confirmable GET 
request with observe option for resource /obs 


2 


Check 


The request sent by client contains: 
. Type = (CON) 

• Code = 1 (GET) 

• Token value = a value generated by the client 

• Observe option = empty 


3 


Check 


Server sends the response containing: 
. Type = 2 (ACK) 

• Content-format of the resource /obs 

• Token value = same as one found in the step 2 

• Observe option with a sequence number 


4 
(note 1) 


Check 


Server sends a notification containing: 

• Type = (CON) 

• Content-format = same as one found in the step 3 

• Token value = same as one found in the step 2 

• Observe option indicating increasing values 


5 


Check 


Client displays the received information 


6 


Check 


Client sends an ACK 


7 
(note 2) 


Stimulus 


Update the /obs resource of the server's resource with a new 
payload having the same Content-Format (either locally or by 
having another CoAP client perform a DELETE request) 


8 
(note 3) 


Check 


Server notifications contains: 
. Type = (CON) 

• Content-format = same as one found in the step 3 

• Token value = same as one found in the step 2 

• Observe option indicating increasing values 

• Payload = the new value sent at step 8 


9 


Verify 


Client displays the new value of /obs sent in step 8 


10 


Check 


Client sends an ACK 


NOTE 1 : Steps 4-6 are in a loop. 

NOTE 2: Steps 7-9 are asynchronous to the loop 4-6. 

NOTE 3: Steps 8-10 are in a loop (the same loop at steps 4-6 but /obs is updated). 
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